Wymagania zgodności szyfrowania: RODO, HIPAA i więcej

Zgodność szyfrowania transferów plików sprowadza się do pięciu regulacji i dwóch prawd. Art. 32 RODO wymaga szyfrowania „tam gdzie jest to stosowne" dla danych osobowych. HIPAA 164.312(a)(2)(iv) i (e)(2)(ii) regulują kontrolę dostępu i bezpieczeństwo transmisji. PCI DSS 4.0 Wymaganie 4 nakazuje silną kryptografię podczas transmisji. SOC 2 Common Criteria 6.7 obejmuje transmisję danych poufnych. CCPA (wraz z poprawkami CPRA) tworzy bezpieczną przystań dla zaszyfrowanych danych naruszonych. Dwie prawdy: TLS w tranzycie to podłoga, nie sufit; szyfrowanie w spoczynku po stronie serwera nie pomaga, jeśli dostawca trzyma klucze.

Art. 32 RODO i standard „stosowności"

Art. 32 ust. 1 lit. a RODO explicite wymienia szyfrowanie jako środek techniczny zapewniający „poziom bezpieczeństwa odpowiedni do ryzyka". Motyw 83 wyjaśnia, że stosowność uwzględnia stan techniki, koszty, charakter przetwarzania i ryzyko. W praktyce 2026 roku stosowny oznacza AES-256-GCM lub ChaCha20-Poly1305 w tranzycie, plus szyfrowanie po stronie klienta gdy dane obejmują szczególne kategorie z art. 9 RODO (zdrowie, biometria, poglądy polityczne). Wytyczne EROD z 2024 roku w sprawie przekazywania danych do państw trzecich traktują szyfrowanie end-to-end jako środek uzupełniający, który może legalizować transfery do krajów bez decyzji o adekwatności po Schrems II.

HIPAA Security Rule i standard „adresowalny"

Wymagania szyfrowania HIPAA są technicznie „adresowalne", a nie „wymagane", co wprowadza ludzi w błąd. 45 CFR 164.312(a)(2)(iv) i 164.312(e)(2)(ii) mówią, że musisz wdrożyć szyfrowanie lub udokumentować, dlaczego jest ono nieuzasadnione. Wytyczne OCR z 2024 roku są jasne: „adresowalny nie oznacza opcjonalny". Faktyczny standard to kryptografia zatwierdzona NIST FIPS 140-3, co w praktyce oznacza AES-256 w spoczynku i TLS 1.2+ w tranzycie. Serwis transferu obsługujący PHI (badania DICOM, wiadomości HL7, dokumenty CCDA) musi oferować BAA i wykazać kontrolę dostępu zgodnie z 164.308(a)(4).

PCI DSS 4.0 o sile kryptograficznej

Wymaganie 4.2.1 (obowiązujące od 31 marca 2025) nakazuje silną kryptografię podczas transmisji przez otwarte sieci. Silna oznacza minimum TLS 1.2, zalecane TLS 1.3, wyłącznie z zatwierdzonymi zestawami szyfrów (bez RC4, bez 3DES, bez szyfrów eksportowych). Wymaganie 3.5 obejmuje zarządzanie kluczami: klucze muszą być przechowywane oddzielnie od zaszyfrowanych danych, rotowane zgodnie ze zdefiniowaną polityką i niszczone gdy nie są już potrzebne. Wymaganie 12.3.3 wymaga udokumentowanego inwentarza zestawów szyfrów i protokołów — jeśli Twój dostawca transferu używa TLS 1.3 z hybrydowym X25519-MLKEM, to należy do dokumentacji zgodności.

SOC 2 Common Criteria dla transmisji

CC6.7 wymaga, aby „podmiot ograniczał transmisję, przemieszczanie i usuwanie informacji do upoważnionych użytkowników wewnętrznych i zewnętrznych". W praktyce audytorzy proszą o dowody: konfiguracji TLS (uruchom Qualys SSL Labs, oczekuj A+), logów dostępu z retencją 12-miesięczną, polityki zarządzania kluczami szyfrowania i podręcznika reagowania na incydenty. CC7.2 obejmuje wykrywanie; ścieżka audytu transferu to spełnia. Raporty Typu II wymagają sześciomiesięcznej obserwacji, więc narzędzie do transferu plików przyjęte w połowie audytu może nie liczyć się do następnego cyklu.

CCPA, CPRA i bezpieczna przystań szyfrowania

California Civil Code 1798.150(a) tworzy prywatne prawo do powództwa za naruszenia „niezaszyfrowanych i niezredagowanych danych osobowych". Przekład: jeśli naruszone dane były zaszyfrowane kluczami, których atakujący nie uzyskał, jesteś chroniony przed odszkodowaniami ustawowymi w wysokości 100–750 USD na konsumenta za incydent. To sprawiło, że silne szyfrowanie stało się finansowo opłacalne dla firm obsługujących klientów z Kalifornii. Działania egzekucyjne prokuratora generalnego z 2024 roku przeciwko Sephora i DoorDash obie cytowały niepowodzenia szyfrowania w spoczynku; żadna z firm nie byłaby winna odszkodowań ustawowych, gdyby bazy danych były szyfrowane kluczami chronionymi HSM.

Stanowe przepisy o powiadomieniu o naruszeniu i co oznacza „zaszyfrowany"

Wszystkie 50 stanów USA posiada przepisy o powiadomieniu o naruszeniu i większość zawiera wyjątek dla szyfrowania — ale definicja się różni. Nowojorski Shield Act wymaga „szyfrowania, które czyni dane nieczytelne lub bezużyteczne". Illinois PIPA (815 ILCS 530) wymaga szyfrowania „czyniącego informacje nieczytelne lub niezrozumiałe". Massachusetts 201 CMR 17.00 określa „transformację danych za pomocą procesu algorytmicznego". Wspólny mianownik: AES-128 lub silniejszy, klucze niedostępne dla atakującego. Serwis transferu, który przechowuje kryptotekst i klucze na tym samym serwerze, nie kwalifikuje się — atakujący, który naruszy serwer, dostaje oba.

Wymagania dotyczące transferów transgranicznych po Schrems II

Przesyłanie plików z UE do USA, Indii lub innego miejsca bez decyzji o adekwatności wymaga środków uzupełniających zgodnie z wyrokiem TSUE Schrems II (C-311/18). Szyfrowanie end-to-end, przy którym serwis transferu nie ma dostępu do plaintextu, to złoty standard środka uzupełniającego zgodnie z Zaleceniami EROD 01/2020. To przesuwa analizę prawną: przy szyfrowaniu po stronie klienta Twój zasobnik S3 w USA przechowuje kryptotekst, którego dostawca nie może odczytać, więc wnioski o ujawnienie na mocy FISA 702 nie przynoszą nic użytecznego. Udokumentuj to w Ocenie Skutków Transferu (TIA) i powołaj się na to w zabezpieczeniach z art. 46 RODO.

Branżowe wymogi uzupełniające warte znajomości

Reguła FINRA 4511 wymaga od domów maklerskich przechowywania elektronicznych zapisów w formacie nienadpisywalnym, nieskasowalnalnym przez sześć lat — magazyn WORM z szyfrowaniem spełnia ten wymóg. FERPA (20 USC 1232g) obejmuje dokumentację studencką; nie ma explicite wymogu szyfrowania, ale wytyczne Departamentu Edukacji z 2023 roku traktują je jako wymagane dla „informacji katalogowych traktowanych jako poufne". ITAR i EAR (kontrola eksportu) zabraniają transmisji danych technicznych o uzbrojeniu bez dostępu wyłącznie dla osób z USA — zaszyfrowany transfer z odbiorcami o zweryfikowanym obywatelstwie to zgodny wzorzec. Model szyfrowania HexaTransfer spełnia wymagania techniczne większości z nich, choć nadal potrzebujesz kontroli procesowych (BAA, przeglądy dostępu, udokumentowane polityki).

Dokumentowanie drogi do dającej się obronić zgodności

Audytorzy nie oceniają Cię za perfekcyjne bezpieczeństwo; oceniają za udokumentowane rozsądne bezpieczeństwo. Utrzymuj inwentarz kryptograficzny (algorytmy, rozmiary kluczy, harmonogramy rotacji), diagram przepływu danych pokazujący gdzie transfery plików przekraczają granice zaufania, i ocenę dostawcy obejmującą certyfikaty Twojego serwisu transferu (ISO 27001, SOC 2, dostępność HIPAA BAA). Przeglądaj corocznie. Gdy naruszenie nastąpi — a nastąpi — ta dokumentacja oddziela karę 50 000 € od kary 5 000 000 €.

Wypróbuj na hexatransfer.com — bezpłatnie, bez konta, do 10 GB.