Bezpieczeństwo danych zdrowotnych w aplikacjach i urządzeniach medycznych: o co pytać sprzedawcę i producenta

Dlaczego dane zdrowotne są wyjątkowo wrażliwe

Dane zdrowotne a „zwykłe” dane osobowe – kluczowe różnice

Dane zdrowotne należą do najbardziej intymnych informacji o człowieku. Opisują przeszłe i obecne choroby, nałogi, życie seksualne, zdrowie psychiczne, niepełnosprawności, wyniki badań, a często także informacje genetyczne. W przeciwieństwie do adresu e‑mail czy numeru telefonu, ich ujawnienia nie da się „cofnąć” prostą zmianą hasła czy konta.

Prawo (np. RODO) klasyfikuje dane zdrowotne jako dane szczególnej kategorii. Oznacza to, że podlegają one ostrzejszym zasadom przetwarzania: wymagają szczególnych podstaw prawnych, wyższego poziomu zabezpieczeń oraz dokładniejszej dokumentacji. Wynika to z ich potencjału do wyrządzania szkody, jeśli trafią w niepowołane ręce.

Najprostszy test wrażliwości danych: zadać sobie pytanie, jak bardzo byłoby krępujące, gdyby informacja trafiła do całej firmy, sąsiadów czy ubezpieczyciela. Wynik poziomu glukozy, diagnoza psychiatryczna czy historia aborcji wypadają w tym teście zdecydowanie gorzej niż numer telefonu czy lokalizacja sklepu, w którym robimy zakupy.

Skutki wycieku danych zdrowotnych dla pacjenta

Wyciek danych zdrowotnych nie kończy się na „nieprzyjemnym incydencie”. Może oznaczać długotrwałe konsekwencje finansowe, zawodowe i społeczne. Przykładowo, jeśli ubezpieczyciel – legalnie lub nielegalnie – wejdzie w posiadanie pełnej historii leczenia, może:

• zaoferować mniej korzystne warunki ubezpieczenia na życie lub zdrowotnego,
• odmówić zawarcia umowy, powołując się na podwyższone ryzyko,
• w przyszłości kwestionować wypłatę świadczeń, powołując się na „ukrytą chorobę”.

Pracodawca, który dowie się o długotrwałej chorobie przewlekłej lub zaburzeniach psychicznych, może z kolei podejmować decyzje personalne w sposób mocno niekorzystny dla pracownika – od omijania przy awansach po „ciche” wypychanie z firmy. Oficjalnie jest to nielegalne, ale w praktyce udowodnienie dyskryminacji bywa trudne.

Dochodzi do tego wymiar społeczny: ujawnienie informacji o niepłodności, HIV, depresji czy przebytych zabiegach może mocno wpłynąć na relacje rodzinne, związek, pozycję w lokalnej społeczności. Jeśli dodamy do tego możliwość łączenia danych z aplikacji zdrowotnych z aktywnością w mediach społecznościowych, powstaje profil człowieka niezwykle szczegółowy i trudny do kontrolowania.

Eksplozja ilości danych – aplikacje, opaski, telemedycyna

Jeszcze kilkanaście lat temu gros danych zdrowotnych powstawało tylko w gabinetach lekarskich i szpitalach. Dziś ogromna ich część generowana jest przez aplikacje mobilne i urządzenia noszone – w dużej mierze poza systemem ochrony zdrowia. Należą do nich m.in.:

• opaski i zegarki monitorujące tętno, sen, aktywność, poziom stresu,
• domowe glukometry, ciśnieniomierze, pulsoksymetry połączone z aplikacją,
• aplikacje do śledzenia cyklu menstruacyjnego, diety, treningów,
• platformy telemedyczne obsługujące wideokonsultacje i zdalne EKG.

Każde z tych narzędzi zapisuje i przesyła dane. Niekoniecznie tylko lekarzowi – często także do chmury producenta, do systemów analitycznych, a potem nierzadko do podmiotów trzecich. Ilość tych informacji rośnie lawinowo, a ślad cyfrowy pacjenta staje się coraz bardziej kompletny.

Kluczowy problem: wiele tych narzędzi powstaje w logice „startupowej” – szybko na rynek, a kwestie bezpieczeństwa dopracujemy później. To, co dla twórcy jest „produktem technologicznym”, w praktyce staje się wirtualną dokumentacją medyczną tysięcy użytkowników.

Sprzedawca i producent jako strażnicy danych

Sprzedawca i producent aplikacji medycznej lub urządzenia nie są tylko dostawcami sprzętu. W praktyce stają się strażnikami danych zdrowotnych. To przez ich rozwiązania dane są zbierane, przechowywane, przesyłane i analizowane. To ich decyzje projektowe decydują o tym, czy:

• dane są szyfrowane czy przesyłane „otwartym tekstem”,
• profile użytkowników są łączone z innymi źródłami informacji,
• dane są sprzedawane dalej w celach marketingowych lub badawczych,
• aktualizacje bezpieczeństwa są wydawane regularnie, czy „od święta”.

Z tego powodu rozmowa z dostawcą nie może ograniczać się do pytania o funkcje kliniczne i cenę. Pytania o bezpieczeństwo danych zdrowotnych, o odpowiedzialność producenta za wyciek danych oraz o procedury reagowania na incydenty są tak samo ważne jak pytania o dokładność pomiaru czy czas pracy baterii.

Podstawy prawne i regulacyjne – co musi spełniać aplikacja i urządzenie

RODO / GDPR w praktyce aplikacji i urządzeń medycznych

RODO (GDPR) określa, że informacje o zdrowiu to dane szczególnej kategorii, których przetwarzanie jest co do zasady zabronione, chyba że zachodzi jedna z przewidzianych w rozporządzeniu przesłanek (np. zgoda, cele medyczne, interes publiczny w dziedzinie zdrowia). W praktyce oznacza to, że twórca aplikacji zdrowotnej czy producent urządzenia połączonego z chmurą musi bardzo dokładnie określić, kto jest administratorem danych, a kto podmiotem przetwarzającym.

Administrator to ten podmiot, który decyduje o celach i sposobach przetwarzania. Może to być:

• placówka medyczna wdrażająca system,
• sam producent aplikacji (jeśli kieruje ją do użytkowników indywidualnych),
• wspólnie – np. klinika i dostawca platformy telemedycznej.

Podmiot przetwarzający (procesor) to ten, który działa „w imieniu” administratora – np. firma hostingowa, dostawca chmury, integrator systemu. Rozróżnienie jest ważne, bo od niego zależy, kto odpowiada wobec pacjenta za naruszenia, komu pacjent może zgłosić żądanie dostępu do danych, ich usunięcia czy przeniesienia.

W rozmowie ze sprzedawcą lub producentem warto doprecyzować:

• kto będzie administratorem danych w planowanym modelu wdrożenia,
• jak wyglądają wzory umów powierzenia przetwarzania danych,
• czy platforma wspiera realizację praw pacjenta z RODO (dostęp, korekta, ograniczenie, przeniesienie, sprzeciw).

Kiedy aplikacja jest wyrobem medycznym, a kiedy tylko „fitness”

Z punktu widzenia bezpieczeństwa danych zdrowotnych często pojawia się napięcie: producent deklaruje, że jego rozwiązanie to „aplikacja wellness”, podczas gdy funkcjonalnie wygląda ono jak wyrób medyczny. Różnica jest zasadnicza, bo wyrób medyczny podlega restrykcyjnym regulacjom (w UE głównie MDR – Medical Device Regulation) i procedurom oceny zgodności.

Ogólnie rzecz biorąc, aplikacja staje się wyrobem medycznym, jeśli służy m.in. do:

• diagnozowania chorób (np. interpretacja EKG, analiza znamion skóry),
• monitorowania parametrów w procesie leczenia (np. pompa insulinowa sterowana aplikacją),
• planowania lub wspomagania terapii (np. dawki leku, plan rehabilitacji),
• prognozowania przebiegu choroby czy ryzyka zdarzenia zdrowotnego.

Jeżeli aplikacja wyłącznie zlicza kroki, czas snu czy tętno w kontekście rekreacyjnym, najczęściej nie jest wyrobem medycznym. Jednak już funkcja „ryzyko migotania przedsionków na podstawie zapisu z zegarka” może wprowadzić ją w obszar MDR.

Rozmowa ze sprzedawcą powinna zawierać proste pytanie: „Czy produkt posiada status wyrobu medycznego i według jakiej klasyfikacji MDR?”. Jeśli odpowiedź brzmi „tak”, trzeba poprosić o:

• deklarację zgodności lub certyfikat jednostki notyfikowanej,
• instrukcję używania wyrobu medycznego,
• informacje o numerze UDI (unikalnym identyfikatorze urządzenia),
• opis zarządzania ryzykiem, także w zakresie cyberbezpieczeństwa.

Obowiązki producenta i sprzedawcy wobec placówki i pacjenta

Producent wyrobu medycznego ma obowiązek m.in. zapewnić, że produkt jest bezpieczny i działa zgodnie z przeznaczeniem. W nowym podejściu regulacyjnym bezpieczeństwo obejmuje również bezpieczeństwo informacji. Oznacza to konieczność projektowania rozwiązań z uwzględnieniem cyberzagrożeń, aktualizacji oprogramowania i możliwości zgłaszania incydentów.

Sprzedawca i dostawca systemu, który działa na rzecz placówki medycznej lub lekarza, powinni zaoferować:

• jasną dokumentację opisującą, jakie dane są zbierane,
• wzory umów (np. powierzenia przetwarzania danych) dostosowane do RODO,
• procedury serwisowe, aktualizacyjne, odzyskiwania danych po awarii,
• kontakt do inspektora ochrony danych (IOD) lub odpowiedzialnej osoby.

Od strony praktycznej dobrym sygnałem jest, jeśli producent lub dostawca potrafi bez trudu udostępnić politykę bezpieczeństwa, instrukcje dla administratora systemu oraz rekomendacje dot. konfiguracji pod kątem ochrony danych. Brak takich dokumentów albo chaos w odpowiedziach zwykle zapowiada problemy przy audycie bezpieczeństwa aplikacji zdrowotnej.

Certyfikaty i normy – o co konkretnie pytać

Normy i certyfikaty nie zastąpią zdrowego rozsądku, ale są dobrym filtrem jakości. W obszarze bezpieczeństwa danych i zarządzania jakością w technologiach medycznych najczęściej pojawiają się:

• ISO 13485 – system zarządzania jakością dla wyrobów medycznych,
• ISO 14971 – zarządzanie ryzykiem w wyrobach medycznych,
• ISO 27001 – system zarządzania bezpieczeństwem informacji,
• ISO 27701 – rozszerzenie ISO 27001 o ochronę danych osobowych.

W rozmowie z dostawcą przydaje się prosta checklista pytań:

• „Czy organizacja posiada certyfikację ISO 13485 / ISO 27001? Na jakie zakresy?”
• „Czy macie udokumentowaną analizę ryzyka pod kątem cyberbezpieczeństwa?”
• „Czy przeprowadzacie regularne audyty bezpieczeństwa i testy penetracyjne?”
• „Czy posiadacie wyznaczonego inspektora ochrony danych lub osobę odpowiedzialną za zgodność z RODO?”

Odpowiedzi nie muszą być idealne, ale powinny być konkretne. Ogólniki typu „tak, dbamy o bezpieczeństwo, proszę się nie martwić” w połączeniu z brakiem dokumentów powinny zapalić czerwoną lampkę.

Jak działa ochrona danych w praktyce – intuicyjny „łańcuch bezpieczeństwa”

Prosty model przepływu danych zdrowotnych

Najłatwiej myśleć o bezpieczeństwie danych zdrowotnych jak o łańcuchu bezpieczeństwa, który zaczyna się i kończy na pacjencie. Przykładowy łańcuch dla typowego rozwiązania (urządzenie + aplikacja + chmura + lekarz) wygląda tak:

1. Pacjent korzysta z urządzenia (np. glukometr, opaska, inhalator) połączonego z aplikacją.
2. Dane są zapisywane lokalnie w aplikacji na smartfonie lub we wbudowanej pamięci urządzenia.
3. Urządzenie / aplikacja przesyła dane przez Internet (Wi‑Fi, LTE) do serwera w chmurze.
4. System w chmurze przechowuje dane, analizuje je, tworzy raporty.
5. Dane lub ich część trafiają do panelu lekarza albo systemu szpitalnego.
6. Na tej podstawie lekarz podejmuje decyzje, a pacjent otrzymuje informację zwrotną.

W każdym z tych punktów coś może pójść nie tak: ktoś może podsłuchać przesył, odgadnąć hasło, zainfekować urządzenie, uzyskać dostęp do konta w chmurze lub wykraść dane z serwera. Dlatego pytania do sprzedawcy warto powiązać właśnie z poszczególnymi ogniwami łańcucha.

Cztery filary bezpieczeństwa: CIA + rozliczalność

Specjaliści mówią o trzech klasycznych filarach bezpieczeństwa: poufność (confidentiality), integralność (integrity) i dostępność (availability). W medycynie dochodzi do tego czwarty – rozliczalność (accountability). W praktyce oznacza to:

• Poufność – czy osoby nieupoważnione nie mogą zobaczyć danych? (szyfrowanie, kontrola dostępu, logowanie).
• Integralność – czy dane nie są niepostrzeżenie zmieniane? (podpisy cyfrowe, kontrola wersji, logi zdarzeń).
• Dostępność – czy dane są dostępne wtedy, gdy są potrzebne do leczenia? (kopie zapasowe, redundancja, SLA).
• Rozliczalność – czy da się ustalić, kto co zrobił z danymi i kiedy? (rejestry operacji, audyt logów).

Każdy z tych filarów przekłada się na konkretne pytania do dostawcy. Przykładowo: „Jak zapewniacie poufność danych na urządzeniu pacjenta?”, „Czy istnieją mechanizmy wykrywania nieautoryzowanych zmian danych?”, „Jaki jest czas przywrócenia systemu po awarii?”, „Czy system rejestruje dostęp lekarzy do danych pacjenta i czy te logi są dostępne dla administratora?”.

Typowe słabe ogniwa w łańcuchu bezpieczeństwa

W większości incydentów bezpieczeństwa nie zawodzi zaawansowana kryptografia, lecz prozaiczne elementy: złe hasła, brak aktualizacji, zbyt szerokie uprawnienia. Przy rozmowie ze sprzedawcą dobrze jest przejść łańcuch krok po kroku i sprawdzić, gdzie może „puścić”.

Do najczęstszych słabych punktów należą:

• urządzenia końcowe pacjentów – stare telefony bez aktualizacji, brak blokady ekranu, instalowanie podejrzanych aplikacji,
• konfiguracja sieci i serwerów – pozostawione domyślne hasła, otwarte porty, brak segmentacji sieci,
• dostępy personelu medycznego – wspólne konta, brak wylogowywania, loginy pozostawione na komputerach w gabinetach,
• integracje między systemami – wymiana plików przez e‑mail, brak szyfrowania przy połączeniu z systemem szpitalnym,
• kopie zapasowe – backup robiony „gdzieś”, ale bez szyfrowania i bez testów przywracania.

Rozmowa ze sprzedawcą nie powinna ograniczać się do samej aplikacji. Kluczowe jest pytanie, jak rozwiązanie zachowuje się w realnym środowisku – z lekarzem, pacjentem i infrastrukturalnymi ograniczeniami placówki.

Rola użytkownika i „bezpieczne domyślne ustawienia”

Nawet najlepiej zabezpieczony system można osłabić, jeśli użytkownik zostanie pozostawiony sam sobie. Dlatego producenci powinni stosować zasadę privacy by default – czyli domyślnie włączone ustawienia chroniące prywatność i bezpieczeństwo.

W praktyce oznacza to m.in. że:

• konto pacjenta od początku ma wymóg silnego hasła lub logowania biometrycznego,
• włączone jest szyfrowanie bazy lokalnej w aplikacji, a wyłączenie go nie jest możliwe,
• dostęp lekarza lub opiekuna do danych pacjenta wymaga potwierdzenia zgody w aplikacji,
• nie ma domyślnie aktywnych funkcji „dzielenia się postępami” z innymi serwisami czy mediami społecznościowymi,
• aplikacja sama przypomina o aktualizacjach i nie pozwala długo działać na przestarzałej wersji krytycznej dla bezpieczeństwa.

Podczas spotkania ze sprzedawcą dobrze dopytać, które zabezpieczenia są „twardo wbudowane” w system, a które wymagają ręcznej konfiguracji przez administratora lub użytkownika. Im mniej zależy od dobrej woli i technicznej wiedzy pacjenta, tym lepiej.

Dane „na urządzeniu” i „w chmurze” – co konkretnie sprawdzić

Bezpieczeństwo danych na smartfonie i urządzeniu medycznym

Dane przechowywane bezpośrednio na urządzeniu pacjenta są atrakcyjnym celem – łatwiej ukraść telefon niż włamać się do serwera dużego dostawcy chmury. Stąd kilka kluczowych kwestii, które warto omówić z producentem:

• Czy dane są szyfrowane „w spoczynku”? – chodzi o to, czy baza danych w aplikacji, pamięć glukometru czy rejestratora EKG jest zaszyfrowana tak, aby samo fizyczne przejęcie urządzenia nie pozwalało odczytać informacji.
• Jak wygląda blokada dostępu do aplikacji? – czy poza kodem/PIN do telefonu aplikacja może wymagać dodatkowej autoryzacji (PIN, odcisk palca, rozpoznawanie twarzy)?
• Czy aplikacja działa na zrootowanych / zrootowanych lub „odblokowanych” urządzeniach? – jeśli tak, dobrze zapytać, jakie dodatkowe mechanizmy kontrolne stosuje. Część rozwiązań medycznych po wykryciu takiego stanu po prostu odmawia działania lub ogranicza funkcjonalność.
• Jak długo dane są przechowywane lokalnie? – czy są automatycznie usuwane po synchronizacji z chmurą, czy pozostają w urządzeniu przez cały okres korzystania z aplikacji.
• Co dzieje się po odinstalowaniu aplikacji? – czy dane lokalne są bezpiecznie kasowane (np. nadpisywane), czy pozostają w pamięci urządzenia.

Przykładowa sytuacja z praktyki: pacjent sprzedaje swój stary telefon z zainstalowaną aplikacją zdrowotną, ale bez jej odinstalowania. Jeśli system nie szyfruje danych lokalnych lub nie wiąże ich z kontem użytkownika, nowy właściciel może uzyskać wgląd w historię pomiarów czy wizyt.

Przesyłanie danych – od Bluetooth po HTTPS

Drugi krytyczny fragment łańcucha to przesył danych między urządzeniem a aplikacją i dalej – między aplikacją a chmurą. Tutaj liczy się przede wszystkim to, czy komunikacja jest odpowiednio szyfrowana i uwierzytelniana.

W pytaniach do sprzedawcy dobrze uwzględnić:

• Jak zabezpieczona jest komunikacja Bluetooth / BLE? – czy jest stosowane parowanie z autoryzacją, czy można łatwo „podsłuchać” transmisję? Czy aplikacja weryfikuje, że łączy się z właściwym urządzeniem, a nie jego imitacją?
• Czy połączenia z serwerem są szyfrowane (TLS/HTTPS)? – praktycznie standard, lecz wciąż zdarzają się wyjątki, zwłaszcza w komunikacji z wewnętrznymi serwerami integracyjnymi.
• Czy aplikacja weryfikuje certyfikat serwera (certificate pinning)? – to dodatkowa ochrona przed atakami „man in the middle”, np. na publicznych sieciach Wi‑Fi.
• Czy istnieją mechanizmy ograniczające liczbę prób logowania? – chodzi o ochronę przed „zgadywaniem” haseł (brute force).

Dobrą praktyką jest również stosowanie kanałów komunikacji specyficznych dla kraju lub regionu, jeśli wymaga tego prawo (np. szyfrowowane kanały do wymiany danych z systemami e‑zdrowia). Można wprost zapytać, jak wygląda integracja z lokalną infrastrukturą zdrowotną i czy spełnia krajowe wytyczne bezpieczeństwa.

Bezpieczeństwo chmury – pytania do dostawcy infrastruktury

Chmura bywa postrzegana jako coś abstrakcyjnego, tymczasem to po prostu cudze serwery, centrum danych i procedury, za które płaci się w modelu usługowym. Kluczem jest ustalenie, czyja to chmura i na jakich zasadach działa.

Krytyczne pytania do sprzedawcy rozwiązania medycznego obejmują m.in.:

• Gdzie fizycznie przechowywane są dane? – w jakim kraju, w jakich centrach danych. Dla danych zdrowotnych ważne jest, czy pozostają w Europejskim Obszarze Gospodarczym, czy też są przekazywane poza EOG (np. do USA, Azji).
• Jaki jest model chmury? – chmura publiczna (np. duzi globalni dostawcy), prywatna, hybrydowa. Każdy model niesie inne ryzyka i obowiązki umowne.
• Czy dostawca chmury ma certyfikaty bezpieczeństwa (ISO 27001, SOC 2)? – same certyfikaty nie wystarczą, ale pokazują poziom dojrzałości procesu.
• Jak wygląda kontrola dostępu administratorów chmury do danych? – czy pracownicy dostawcy mogą przeglądać dane w postaci niezaszyfrowanej, w jakich sytuacjach, pod jakim nadzorem.
• Czy dane w chmurze są szyfrowane „w spoczynku” i kto zarządza kluczami? – idealnie, jeśli kluczami szyfrującymi zarządza administrator systemu po stronie placówki, a nie wyłącznie dostawca.

Dobrze też dopytać, jak rozwiązano separację danych między klientami. Jeżeli ta sama instancja systemu obsługuje wielu odbiorców (np. różne kliniki), istotne jest, aby nie było ryzyka „przeskoczenia” danych między tenantami, czyli logicznymi wydzieleniami w chmurze.

Kopie zapasowe i procedury odtwarzania po awarii

Bezpieczeństwo to nie tylko ochrona przed wyciekiem, lecz także przed utratą danych. Dla pacjenta równie groźna może być sytuacja, w której z powodu awarii systemu znika historia pomiarów, wyniki badań czy zapis konsultacji.

Podczas rozmów wdrożeniowych warto zapytać:

• Jak często wykonywane są kopie zapasowe? – raz na dobę, częściej, rzadziej; czy dostępna jest opcja dopasowania do potrzeb placówki.
• Gdzie są przechowywane backupy? – w tym samym centrum danych, w innej lokalizacji, w innym kraju. Dobrą praktyką jest geograficzne rozproszenie.
• Czy kopie zapasowe są szyfrowane? – niedoszacowany, ale istotny obszar: wycieki często dotyczą źle zabezpieczonych backupów.
• Jak wygląda procedura odtwarzania danych? – czy była testowana w warunkach zbliżonych do realnych, jaki jest deklarowany czas przywrócenia usług (RTO) i maksymalna dopuszczalna utrata danych (RPO).
• Czy placówka ma dostęp do własnych kopii eksportowych? – np. okresowe zrzuty danych w standardowym formacie (FHIR, HL7, CSV) jako dodatkowe zabezpieczenie.

Ciekawostka: w wielu głośnych incydentach ransomware w szpitalach problemem nie był sam atak, lecz brak sprawnych i aktualnych kopii zapasowych. Oprogramowanie szyfrowało dane, a placówki nie miały z czego odtworzyć dokumentacji medycznej.

Usuwanie i przenoszenie danych – „cyfrowe zapominanie” w praktyce

Pacjent ma prawo zażądać usunięcia danych (w określonych ramach) lub ich przeniesienia do innego dostawcy. To, czy będzie to możliwe, zależy w dużej mierze od sposobu, w jaki aplikacja i chmura przechowują informacje.

Kluczowe kwestie do omówienia z producentem:

• Czy system umożliwia selektywne usuwanie danych pacjenta? – nie tylko „dezaktywację konta”, lecz realne wykasowanie z baz operacyjnych i kopii zapasowych w rozsądnym czasie.
• Jak realizowana jest anonimizacja lub pseudonimizacja? – np. gdy dane mają pozostać w systemie do celów statystycznych, ale bez możliwości identyfikacji konkretnej osoby.
• Czy dostępna jest funkcja eksportu danych dla pacjenta? – w jakim formacie (np. PDF, CSV, standardy medyczne typu FHIR), czy można te dane wczytać do innych systemów.
• Jak długo przechowywane są logi systemowe związane z kontem pacjenta? – logi też często zawierają dane osobowe (np. identyfikatory, adresy IP) i podlegają zasadom retencji.

Warto dopytać, czy proces usuwania jest udokumentowany i czy producent potrafi przedstawić schemat obiegu takiego żądania – od zgłoszenia pacjenta, przez weryfikację tożsamości, aż po fizyczne usunięcie wpisów w bazach.

Zgody, prywatność i profilowanie – jak chronić pacjenta przed „nadmiernym” użyciem danych

Świadoma zgoda a „zgoda na wszystko jednym kliknięciem”

W aplikacjach zdrowotnych często pojawia się pokusa, aby jednym przyciskiem „zaakceptować wszystko” – regulamin, politykę prywatności, udostępnianie danych partnerom. Dla pacjenta to wygodne, ale rodzi ryzyko, że zgoda nie jest ani świadoma, ani dobrowolna.

Przy wyborze rozwiązania medycznego warto sprawdzić, jak wygląda interfejs zgód:

• czy zgody są rozbite na kategorie – osobno na przetwarzanie w celu leczenia, osobno na marketing, na badania naukowe, na udostępnianie partnerom technologicznym,
• czy pacjent może odmówić zgody dodatkowej (np. marketingowej) bez utraty dostępu do leczenia,
• czy treść zgody jest napisana językiem zrozumiałym, bez żargonu prawnego,
• czy aplikacja ułatwia późniejsze wycofanie zgody – np. jednym przełącznikiem w ustawieniach, a nie poprzez skomplikowaną korespondencję mailową.

Dobrą praktyką jest też prezentowanie pacjentowi krótkiego „streszczenia w pigułce” – kilku zdań wyjaśniających, co stanie się z jego danymi, zanim zagłębi się w pełny dokument polityki prywatności.

Różnica między danymi potrzebnymi do leczenia a danymi „dodatkowymi”

Nie wszystkie dane zbierane przez aplikację są niezbędne do leczenia. Część z nich służy wygodzie (np. dane o aktywności fizycznej spoza kontekstu klinicznego), część – rozwojowi produktu (statystyki działania systemu), a część – marketingowi.

Rozmowa ze sprzedawcą powinna objąć kilka praktycznych kwestii:

• Jakie dane są niezbędne do działania funkcji medycznych? – np. monitorowania glikemii, dawkowania leku, telekonsultacji.
• Jakie dane są opcjonalne i na jakiej podstawie prawnej są przetwarzane? – np. ankiety satysfakcji, dodatkowe dane o stylu życia.
• Czy istnieje możliwość ograniczenia zbierania danych do niezbędnego minimum? – np. tryb „minimalnych danych”, który wyłącza elementy marketingowe i analityczne.
• Czy pacjent ma dostęp do listy kategorii danych, które są o nim gromadzone?

Wyraźne oddzielenie tego, co „konieczne”, od tego, co „dodatkowe”, ułatwia pacjentowi realną kontrolę nad swoją prywatnością i zmniejsza ryzyko zarzutu, że zgody były wymuszone.

Profilowanie i automatyczne podejmowanie decyzji

Jak rozpoznać profilowanie w aplikacji zdrowotnej

Profilowanie brzmi technicznie, ale w praktyce sprowadza się do tworzenia „obrazu” pacjenta na podstawie jego danych i wykorzystywania tego obrazu do podejmowania decyzji. Czasem jest to pożyteczne (np. lepsze dopasowanie zaleceń), a czasem wchodzi w strefę ryzyka, zwłaszcza gdy w grę wchodzi reklama, scoring ubezpieczeniowy albo utrudniony dostęp do świadczeń.

Dobrym pierwszym krokiem jest zwykłe zadanie pytania: „Czy wasz system dokonuje profilowania pacjentów?”. Jeśli sprzedawca odpowiada wymijająco, warto doprecyzować, o jakie konkretne działania chodzi. Pomóc może kilka doprecyzowujących pytań:

• Czy aplikacja tworzy kategorie pacjentów (np. „wysokie ryzyko”, „niska aktywność”, „nieregularne przyjmowanie leków”) na podstawie danych z urządzeń, ankiet i historii choroby?
• Czy na podstawie tych kategorii są podejmowane decyzje wpływające na opiekę – np. częstsze przypomnienia, dodatkowe telekonsultacje, ograniczenie określonych funkcji?
• Czy profilowanie służy również celom innym niż medyczne – np. dopasowaniu reklam suplementów, ofert ubezpieczeniowych, programów lojalnościowych?
• Czy pacjent jest informowany o tym, że podlega profilowaniu i w jakim celu się to odbywa?

Jeżeli profilowanie ma realny wpływ na sytuację pacjenta (np. automatyczne przyznanie lub odmowa świadczenia, zmiana składki ubezpieczeniowej), uruchamiają się dodatkowe wymogi prawne. Producent powinien wtedy jasno przedstawić, jak można zakwestionować decyzję systemu i zażądać oceny przez człowieka.

Jakich zgód wymaga profilowanie – granice „legitimate interest”

Częstym polem nieporozumień jest podstawa prawna profilowania. Dostawcy powołują się czasem na tzw. „uzasadniony interes” (legitimate interest), podczas gdy przy danych zdrowotnych próg ochrony jest dużo wyższy.

W rozmowie z producentem warto dopytać o trzy scenariusze:

• Profilowanie ściśle medyczne – np. algorytm analizuje wyniki EKG, ciśnienia, poziom glikemii i grupuje pacjentów pod kątem ryzyka zawału czy hipoglikemii. Tego typu działania zwykle mieszczą się w zakresie świadczenia usług zdrowotnych, ale i tak wymagają przejrzystej informacji, jak działa algorytm i jakie ma ograniczenia.
• Profilowanie „użytkowe” – system analizuje sposób korzystania z aplikacji, by poprawić interfejs, kolejność wyświetlania funkcji czy obciążenie serwerów. To bliżej klasycznych analiz użycia, choć przy danych zdrowotnych nawet tu trzeba uważać na zakres i czas przechowywania danych.
• Profilowanie marketingowe – na podstawie historii choroby, listy leków czy stylu życia pojawiają się reklamy lub oferty komercyjne. To najbardziej wrażliwy obszar i zazwyczaj wymaga osobnej, wyraźnej zgody, którą można łatwo wycofać.

Jeżeli dostawca twierdzi, że profilowanie marketingowe opiera się na „uzasadnionym interesie”, to znak ostrzegawczy. Przy danych zdrowotnych ryzyko dyskryminacji i naruszenia prywatności jest na tyle duże, że bardziej konserwatywne podejście (jasna zgoda, precyzyjny zakres, możliwość wyłączenia) jest standardem, a nie luksusem.

Transparentność algorytmów – co pacjent i placówka powinni wiedzieć

Nowoczesne aplikacje i urządzenia medyczne coraz częściej wykorzystują algorytmy uczenia maszynowego lub inne „inteligentne” mechanizmy. Nie chodzi o to, by producent ujawniał całą recepturę, lecz by przyznał, jakie dane są analizowane i co z tego wynika dla pacjenta.

Przy ocenie rozwiązania można zadać kilka bardzo praktycznych pytań:

• Jakie typy danych wchodzą do algorytmu? – wyniki badań, dane z czujników, informacje z ankiet, dane lokalizacyjne?
• Czy w algorytm wchodzą dane z innych źródeł niż stricte medyczne – np. deklaracje dotyczące pracy, nałogów, zwyczajów zakupowych?
• Czy lekarz widzi, na jakiej podstawie algorytm wydał rekomendację – choćby w formie listy głównych czynników ryzyka, a nie tylko „wysokie/średnie/niskie”?
• Jak często algorytm jest weryfikowany klinicznie i czy wyniki takich walidacji są dostępne (choćby w skrócie)?

Przykład z życia: system do zdalnego monitorowania kardiologicznego zaczął generować dużo fałszywych alarmów w jednej z grup wiekowych. Dopiero analiza wejściowych danych ujawniła, że algorytm „nauczył się” błędnego wzorca z przełamanej statystyki. Gdyby klinika nie miała dostępu do informacji o sposobie działania systemu, trudno byłoby podważyć jego rekomendacje.

Śledzenie aktywności, lokalizacji i zachowań – granice monitorowania

Aplikacje zdrowotne potrafią dziś zbierać znacznie więcej niż tylko wyniki badań: kroki, sen, tętno spoczynkowe, lokalizację, częstotliwość używania telefonu. Z punktu widzenia producenta to kopalnia informacji, z punktu widzenia pacjenta – potencjalna mapa całego życia.

Przy ocenie takiego rozwiązania przydaje się krótki „audyt pytaniowy”:

• Jakie dokładnie sensory są wykorzystywane – akcelerometr, GPS, mikrofon, aparat, dane Bluetooth z innych urządzeń?
• Czy lokalizacja jest potrzebna do celu medycznego (np. wezwanie pomocy w razie upadku) czy tylko do analiz statystycznych albo marketingu?
• Czy pacjent może wyłączyć zbieranie lokalizacji bez wyłączania kluczowych funkcji leczenia?
• Czy dane o stylu życia (aktywność, sen, nawyki) są łączone z dokumentacją medyczną, czy przechowywane osobno, w formie zagregowanej?

Przekonujący producent potrafi pokazać, że domyślne ustawienia są „przyjazne prywatności” – nie śledzą więcej, niż to niezbędne, a dodatkowe pomiary są wyraźnie oznaczone i wymagają aktywnego włączenia.

Udostępnianie danych partnerom – kiedy „anonimizacja” naprawdę chroni

Wielu dostawców chętnie zapewnia, że dane udostępniane partnerom są „anonimowe”. Problem w tym, że przy bogatych zbiorach danych zdrowotnych anonimizacja bywa iluzoryczna, bo po połączeniu kilku cech (wiek, region, rzadka choroba) znów można zidentyfikować konkretną osobę.

Przed podpisaniem umowy z producentem warto prześledzić, jak wygląda łańcuch udostępniania danych:

• Komu mogą być przekazywane dane – firmy analityczne, ubezpieczyciele, partnerzy technologiczni, uczelnie, firmy farmaceutyczne?
• W jakiej postaci są przekazywane – w pełni zanonimizowane, pseudonimizowane (zastąpienie imion/PESEL identyfikatorami), czy wprost z danymi osobowymi?
• Czy partnerzy mogą łączyć dane z innymi bazami, co zwiększa ryzyko ponownej identyfikacji pacjenta?
• Czy istnieje mechanizm audytu partnerów – np. prawo placówki do wglądu w to, jak partner obchodzi się z danymi?

Bezpieczniejszym modelem jest takie projektowanie analiz, by dział się one „po stronie dostawcy” na zanonimizowanych lub zagregowanych zbiorach, bez masowego wyprowadzania surowych danych zdrowotnych na zewnątrz ekosystemu.

Minimalizacja danych – jak praktycznie ograniczyć „apetyt” systemu

Zasada minimalizacji mówi: zbieraj tylko to, co rzeczywiście potrzebne. W praktyce oznacza to twarde decyzje projektowe i produktowe, nie tylko ładne hasła w polityce prywatności.

Podczas rozmów o wdrożeniu można szukać takich elementów „higieny danych”:

• Tryby pracy systemu – czy istnieje wersja „podstawowa”, która gromadzi tylko minimum potrzebne klinicznie, oraz tryb rozszerzony, który pacjent może świadomie włączyć?
• Domyślne ustawienia – czy opcje analityczne i marketingowe są od razu włączone (opt-out), czy wymagają aktywnej zgody (opt-in)?
• Okresy przechowywania – czy dane są przechowywane „na zawsze”, czy dla poszczególnych kategorii obowiązują konkretne limity (np. logi techniczne miesiąc, dane kliniczne zgodnie z prawem krajowym)?
• Widoczność dla pacjenta – czy pacjent ma przejrzysty panel, w którym widzi, jakie kategorie danych są o nim zbierane i może je włączyć/wyłączyć?

Niekiedy wystarczy przejrzeć pierwszy ekran rejestracji. Jeżeli od razu wymaga się zgody na szerokie przetwarzanie danych w celach „rozwoju produktu i partnerstw biznesowych”, bez opcji ograniczenia, to sygnał, że minimalizacja nie jest priorytetem.

Cyberbezpieczeństwo w świecie telemedycyny i IoT medycznego – specyfika zagrożeń

Telemedycyna i Internet Rzeczy (IoT) w medycynie oznaczają, że dane płyną nie tylko między serwerem a aplikacją, ale także między dziesiątkami czujników, bramek komunikacyjnych i systemów szpitalnych. To zwiększa komfort pacjenta, ale też liczbę potencjalnych punktów ataku.

Typowe scenariusze zagrożeń obejmują m.in.:

• Przejęcie urządzenia medycznego – np. wstrzykiwacza insuliny, pompy leku, wszczepionego kardiowertera z funkcją zdalnego monitoringu.
• Podsłuch komunikacji między czujnikiem a bramką (hubem) lub między hubem a chmurą.
• Ataki na aplikacje domowe – zainstalowane na prywatnych smartfonach i tabletach, często bez aktualizacji, z wieloma innymi programami.
• Ataki na infrastrukturę szpitalną – ransomware blokujący dostęp do systemów, które zbierają dane z urządzeń IoT.

Nie chodzi tylko o wyciek informacji. W skrajnych przypadkach ingerencja w działanie urządzenia może mieć bezpośrednie skutki zdrowotne, dlatego pytania o cyberbezpieczeństwo nie są „techniczną fanaberią”, ale elementem bezpieczeństwa klinicznego.

Bezpieczeństwo urządzeń medycznych IoT – o co zapytać producenta sprzętu

Urządzenia medyczne, które łączą się z internetem lub lokalną siecią, powinny być projektowane jak „komputery pierwszej kategorii bezpieczeństwa”, a nie jak zwykłe gadżety. Podczas rozmów ze sprzedawcą sprzętu dobrym nawykiem jest przejście przez krótki „checklist” techniczno‑organizacyjny.

Kluczowe zagadnienia to m.in.:

• Aktualizacje oprogramowania (firmware i software) – czy urządzenie otrzymuje regularne poprawki bezpieczeństwa, czy można je aktualizować zdalnie, a jeśli tak, czy aktualizacje są podpisane kryptograficznie (czyli nie da się „podmienić” ich po drodze)?
• Kontrola dostępu – czy dostęp do panelu konfiguracji urządzenia jest chroniony unikalnym hasłem lub certyfikatem, czy używane są domyślne, wspólne dla wszystkich urządzeń dane logowania?
• Lokalne szyfrowanie – czy dane przechowywane w pamięci urządzenia (np. ostatnie pomiary, dziennik zdarzeń) są szyfrowane i co się z nimi dzieje po zresetowaniu lub wycofaniu urządzenia z użycia?
• Rejestrowanie zdarzeń – czy urządzenie prowadzi dziennik ważnych operacji (np. zmiany ustawień, połączenia), który można przeanalizować po incydencie?
• Tryb awaryjny – jak urządzenie zachowa się, gdy utraci łączność z serwerem lub aplikacją? Czy ma „bezpieczny” scenariusz pracy offline?

Dobry producent jest w stanie dostarczyć specyfikację bezpieczeństwa urządzenia, a nie tylko ogólne zapewnienia o „spełnianiu najwyższych standardów”. Im bardziej szczegółowe informacje, tym łatwiej ocenić realny poziom ochrony.

Bezpieczeństwo połączeń i protokołów – jak „podróżują” dane zdrowotne

Telemedycyna to w praktyce ciągła wymiana danych. Ciśnieniomierz w domu pacjenta wysyła pomiary do aplikacji, ta przekazuje je do chmury, a lekarz ogląda je w systemie gabinetowym. Każdy odcinek tego łańcucha powinien być zabezpieczony.

Dobrym punktem odniesienia są pytania o techniczne szczegóły transmisji:

• Czy wszystkie przesyłane dane są szyfrowane „w locie” – np. z wykorzystaniem protokołu TLS w aktualnej i bezpiecznej wersji?
• Czy są obsługiwane tylko nowoczesne, bezpieczne algorytmy szyfrowania, czy też z powodów kompatybilności utrzymano stare, podatne protokoły?
• Jak chronione są połączenia lokalne – np. Bluetooth między czujnikiem a smartfonem, Wi‑Fi w domu pacjenta?
• Czy system wykrywa anomalie w ruchu – np. nagły, masowy transfer danych, próby łączenia z podejrzanych adresów, powtarzające się błędne logowania?

Ciekawym rozwiązaniem są tzw. kanały uprzywilejowane dla danych krytycznych (np. komendy sterujące urządzeniem), które są dodatkowo uwierzytelniane i monitorowane. W razie ataku ryzyko przypadkowej zmiany ustawień medycznych jest wtedy mniejsze.

Ataki ransomware i DDoS w ochronie zdrowia – jak zabezpieczyć się operacyjnie

Najczęściej zadawane pytania (FAQ)

Dlaczego dane zdrowotne w aplikacjach i urządzeniach medycznych są tak wrażliwe?

Dane zdrowotne opisują bardzo intymne obszary życia: choroby, nałogi, zdrowie psychiczne, życie seksualne, wyniki badań, ciążę czy niepłodność. Jeśli raz „wypłyną”, nie da się ich po prostu zmienić jak hasła do konta – ta informacja zostaje z człowiekiem na stałe.

Ujawnienie takich danych może prowadzić do gorszych warunków ubezpieczenia, problemów w pracy, napięć w rodzinie czy stygmatyzacji w środowisku. Dlatego prawo (np. RODO) traktuje je jako szczególnie chronione i nakłada ostrzejsze wymagania techniczne oraz organizacyjne na tych, którzy je przetwarzają.

Jak sprawdzić, czy aplikacja zdrowotna lub urządzenie medyczne jest bezpieczne dla moich danych?

Na początek warto przejrzeć politykę prywatności i regulamin – nawet pobieżnie. Powinny jasno odpowiadać na pytania: jakie dane są zbierane, w jakim celu, komu są przekazywane i jak długo są przechowywane. Brak przejrzystej informacji lub bardzo ogólne sformułowania typu „w celach analitycznych i marketingowych” to sygnał ostrzegawczy.

Przydatne jest też sprawdzenie, czy producent stosuje szyfrowanie (np. połączenie https, informacja o szyfrowaniu danych „w spoczynku” w chmurze) oraz czy regularnie publikuje aktualizacje bezpieczeństwa. Warto zwrócić uwagę, czy firma ma w ogóle opisane procedury reagowania na incydenty (np. jak poinformuje użytkowników o wycieku).

O co konkretnie pytać sprzedawcę lub producenta oprogramowania medycznego w kontekście RODO?

Najważniejsze pytanie brzmi: kto jest administratorem danych, a kto podmiotem przetwarzającym. Innymi słowy – kto decyduje o celach przetwarzania danych (np. klinika, producent aplikacji, obie strony wspólnie), a kto tylko „obsługuje” dane technicznie. Od tego zależy, do kogo pacjent może kierować żądania dostępu, usunięcia czy przeniesienia danych.

Dobrze jest poprosić o wzór umowy powierzenia przetwarzania danych oraz zapytać, czy system technicznie umożliwia realizację praw pacjenta z RODO (np. szybkie wyszukanie danych konkretnej osoby, ich anonimizację lub eksport). Przy wdrożeniach w placówkach medycznych takie elementy nie są dodatkiem, tylko obowiązkiem.

Jak rozpoznać, czy aplikacja to wyrób medyczny, czy tylko aplikacja „fitness”?

Kluczowe jest przeznaczenie produktu. Jeśli aplikacja tylko liczy kroki, mierzy tętno rekreacyjnie czy zapisuje sen „dla ciekawości”, zwykle jest traktowana jako narzędzie wellness. Gdy jednak zaczyna diagnozować, pomagać w leczeniu lub prognozować ryzyko choroby, wchodzi w obszar wyrobu medycznego.

Dobrym testem jest pytanie do sprzedawcy: „Czy to jest wyrób medyczny zgodnie z MDR i jakiej klasy?”. Jeśli odpowiedź jest twierdząca, producent powinien mieć deklarację zgodności, dokumentację wyrobu, numer UDI i opis zarządzania ryzykiem – w tym ryzykiem cyberataków i wycieku danych.

Jakie mogą być skutki wycieku danych zdrowotnych z aplikacji lub urządzenia dla pacjenta?

Skutki często są długofalowe. Ubezpieczyciel, który pozna historię leczenia, może zaproponować droższą polisę lub w przyszłości odmówić wypłaty świadczenia, powołując się na „ukryte” choroby. Pracodawca, znając stan zdrowia, może „po cichu” ograniczać awanse czy unikać powierzania odpowiedzialnych zadań.

Dochodzi aspekt społeczny i emocjonalny – ujawnienie informacji o depresji, HIV, aborcji, niepłodności czy chorobach psychicznych potrafi mocno uderzyć w relacje rodzinne i poczucie bezpieczeństwa. Gdy takie dane połączą się z aktywnością w mediach społecznościowych, powstaje bardzo szczegółowy, trudny do kontrolowania profil człowieka.

Czy producent aplikacji zdrowotnej może sprzedawać moje dane innym firmom?

Może to robić tylko wtedy, gdy ma do tego wyraźną podstawę prawną – najczęściej chodzi o świadomą, dobrowolną zgodę użytkownika lub ściśle określone cele badawcze. Informacja o takim udostępnianiu powinna być jasno opisana w polityce prywatności, a zgoda nie może być „ukryta” w długim formularzu bez realnego wyboru.

Jeśli aplikacja wymaga zgody na przekazywanie danych marketingowych jako warunku korzystania z podstawowych funkcji, to już poważny sygnał ostrzegawczy. W praktyce warto szukać rozwiązań, które albo nie przekazują danych komercyjnie, albo pozwalają na łatwe wyłączenie tego typu udostępnienia.

Jakie obowiązki wobec pacjenta ma producent wyrobu medycznego korzystającego z chmury?

Producent musi zapewnić, że wyrób jest bezpieczny i działa zgodnie z przeznaczeniem – dziś oznacza to także bezpieczeństwo cyfrowe: aktualizacje oprogramowania, łatkę luk bezpieczeństwa, kontrolę dostępu do danych, szyfrowanie oraz udokumentowane procedury reagowania na incydenty.

Jeśli dojdzie do poważnego naruszenia bezpieczeństwa, producent ma obowiązek współpracować z placówką medyczną i organami nadzoru, a pacjenci powinni zostać poinformowani o incydencie i możliwych konsekwencjach. W praktyce warto już przy zakupie zapytać, jak wygląda wsparcie po wdrożeniu oraz kto i w jakim czasie reaguje na zgłoszone problemy z bezpieczeństwem.

Kluczowe Wnioski

• Dane zdrowotne są znacznie bardziej wrażliwe niż „zwykłe” dane osobowe – ujawnienie historii chorób, wyników badań czy informacji o zdrowiu psychicznym może mieć trwałe skutki i nie da się go „odkręcić” jak zmiany hasła czy numeru telefonu.
• Wycieki danych zdrowotnych mogą realnie uderzyć w pacjenta finansowo, zawodowo i społecznie: od gorszych ofert ubezpieczenia i odmowy wypłaty świadczeń, przez nieformalną dyskryminację w pracy, po napięcia w rodzinie i stygmatyzację w otoczeniu.
• Ogromna część informacji o zdrowiu powstaje dziś poza szpitalem – w aplikacjach, opaskach, domowych urządzeniach i na platformach telemedycznych – co tworzy bardzo szczegółowy, trudny do kontrolowania profil użytkownika.
• Wiele cyfrowych narzędzi zdrowotnych jest tworzonych w logice „najpierw funkcje, potem bezpieczeństwo”, przez co aplikacja, która miała być prostym gadżetem, w praktyce staje się wirtualną dokumentacją medyczną tysięcy osób.
• Sprzedawca i producent aplikacji czy urządzenia pełnią rolę strażników danych – to ich decyzje techniczne (szyfrowanie, aktualizacje, łączenie profili, sprzedaż danych dalej) przesądzają o tym, jak duże jest ryzyko nadużyć.
• Rozmowa z dostawcą nie może ograniczać się do funkcji i ceny; równie ważne są pytania o szyfrowanie, miejsce przechowywania danych, model biznesowy (czy dane są monetyzowane) oraz procedury reagowania na incydenty bezpieczeństwa.

Opracowano na podstawie

• Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679 (RODO). Parlament Europejski i Rada UE (2016) – Podstawowe zasady przetwarzania danych osobowych i danych szczególnych kategorii
• Wytyczne 3/2019 dotyczące przetwarzania danych osobowych poprzez urządzenia i aplikacje w kontekście zdrowia. Europejska Rada Ochrony Danych (2020) – Interpretacja RODO dla aplikacji zdrowotnych i urządzeń noszonych
• Ustawa z dnia 10 maja 2018 r. o ochronie danych osobowych. Sejm Rzeczypospolitej Polskiej (2018) – Implementacja RODO w prawie polskim, zasady nadzoru i sankcje
• Raport „Global Data Protection Index – Healthcare Sector”. Deloitte – Analiza ryzyk i incydentów naruszeń danych w sektorze ochrony zdrowia
• Health Data Governance: Privacy, Monitoring and Research. OECD (2015) – Zarządzanie danymi zdrowotnymi, równowaga między ochroną prywatności a innowacją
• Guidance on Mobile Medical Applications. U.S. Food and Drug Administration (2015) – Kryteria, kiedy aplikacja staje się wyrobem medycznym, wymagania regulacyjne
• ISO/IEC 27001 Information security management systems – Requirements. International Organization for Standardization (2022) – Norma systemu zarządzania bezpieczeństwem informacji dla dostawców IT i chmury