SOC 2 i HIPAA w śledzeniu linków: odpowiedź dla działów zakupów

Skracacz URL wydaje się niewielkim elementem podczas weryfikacji działu zakupów. Dwa akapity w ankiecie bezpieczeństwa dostawcy, szybkie poświadczenie, zaznaczenie pola. Potem jednak zespół ds. bezpieczeństwa otwiera diagram architektury i odkrywa, że skracacz znajduje się na ścieżce żądania każdego adresu URL kampanii, każdego linku w e-mailu transakcyjnym i każdego przekierowania z kodu QR. Dwuakapitowy przegląd zmienia się w trzy tygodnie dodatkowych pytań.

Ten wpis odpowiada na pytania, które zespoły ds. zakupów w przedsiębiorstwach faktycznie zadają na temat SOC 2 Type II i HIPAA, oceniając dostawcę usług śledzenia linków. Jest on napisany zarówno dla osób wypełniających ankiety, jak i dla tych, którzy analizują odpowiedzi.

Wersja skrócona#

Elido posiada certyfikat ISO 27001. Proces SOC 2 Type II jest w toku, a planowany termin zakończenia to druga połowa 2026 roku – okno audytowe rozpoczęło się w lutym 2026 r., gromadzenie dowodów trwa do lipca, a raport Type II spodziewany jest do końca czwartego kwartału. HIPAA jest obsługiwany w planach Business i Enterprise po podpisaniu Business Associate Agreement (BAA); bazowe mechanizmy kontrolne są takie same, jak te stosowane w przypadku SOC 2.

Status zgodności z GDPR jest oddzielony od SOC 2 oraz HIPAA i został omówiony w artykule GDPR dla skracaczy URL. Niniejszy wpis skupia się na strukturach atestacyjnych typu US, które napędzają procesy zakupowe w dużych firmach.

Co SOC 2 faktycznie mówi o skracaczu URL#

SOC 2 to raport, a nie certyfikacja. Niezależny audytor (firma CPA w US lub uznana jednostka certyfikująca w EU) bada organizację usługową pod kątem AICPA Trust Services Criteria i wydaje opinię. Type I dokumentuje, że mechanizmy kontrolne są zaprojektowane odpowiednio w danym momencie; Type II dokumentuje, że działały one skutecznie w określonym czasie – zazwyczaj od sześciu do dwunastu miesięcy.

Kryteria Trust Services dzielą się na pięć kategorii. Każdy raport SOC 2 obejmuje Security (bezpieczeństwo); pozostałe cztery (Availability – dostępność, Processing Integrity – integralność przetwarzania, Confidentiality – poufność, Privacy – prywatność) są dołączane według uznania organizacji, w zależności od potrzeb klientów.

Security – kategoria zawsze uwzględniana#

Kryteria Security obejmują kontrolę dostępu, zarządzanie zmianami, monitorowanie, reagowanie na incydenty i ocenę ryzyka. W przypadku skracacza URL najważniejsze mechanizmy kontrolne to:

CC6.1 Logical access (Dostęp logiczny): kto może tworzyć, modyfikować lub usuwać krótkie linki oraz w jaki sposób ten dostęp jest przyznawany i odbierany. Audyt prześledzi konkretnych użytkowników od rekordu zatrudnienia w HR, przez IdP (w przypadku Elido jest to Ory Kratos), po przypisanie ról w obszarze roboczym, sprawdzając, czy ich dostęp został odebrany w wymaganym terminie po rozwiązaniu umowy.
CC6.6 External access (Dostęp zewnętrzny): sposób uwierzytelniania użytkowników zewnętrznych (właścicieli niestandardowych domen, konsumentów API, partnerów integracyjnych) i zakres przyznawanych im uprawnień. Model tokenów API z kluczami idempotencji i zakresem ograniczonym do obszaru roboczego jest tym, co audytor chce zobaczyć.
CC7.2 Monitoring: co jest logowane, gdzie trafiają logi i jak wykrywane są anomalie. Dla usługi przekierowań istotnymi sygnałami są nietypowy wolumen przekierowań w danym obszarze roboczym, aktywacja limitów przepustowości (rate-limit) na brzegu sieci (edge) oraz błędy uwierzytelniania.
CC8.1 Change management (Zarządzanie zmianami): zmiany w kodzie od pull request po wdrożenie, z zachowaniem podziału obowiązków między inżynierem piszącym zmianę a recenzentem, który ją zatwierdza. Audytor sprawdzi próbkę pull requestów i przeanalizuje rekordy zatwierdzeń oraz wdrożeń.

Kryteria Security to także miejsce, w którym SOC 2 wymaga udokumentowanego planu reagowania na incydenty. W przypadku usługi przekierowań istotnymi incydentami są nieautoryzowane tworzenie linków, manipulowanie miejscem docelowym przekierowania oraz wyciek danych poprzez punkty końcowe eksportu analityki. Runbook pod adresem /docs/runbooks/ zawiera procedury dla każdego z tych przypadków.

Availability – druga najczęstsza kategoria#

Availability obejmuje zobowiązania dotyczące czasu sprawnego działania (uptime), planowanie wydajności i odzyskiwanie po awarii. Dla skracacza URL istotne elementy to:

Udokumentowany cel poziomu usług (SLO). Opublikowane SLO dla Elido to 99,95% dostępności przekierowań na kwartał, z oddzielnymi SLO dla panelu (99,9%) i API analitycznego (99,5%).
Dowody testów wydajnościowych. Usługa przekierowań na brzegu sieci (edge) przechodzi ciągłe testy obciążeniowe w środowisku stagingowym; audyt szuka dowodów na to, że zakres wydajności produkcyjnej jest znany i monitorowany pod kątem SLO.
Dowody tworzenia i przywracania kopii zapasowych. Postgres korzysta z Patroni HA z możliwością odzyskiwania do konkretnego punktu w czasie (point-in-time recovery); ClickHouse wykonuje codzienne eksporty do magazynu obiektowego; audytor wymaga logów z próbnego przywracania danych, wykazujących, że cel czasu odzyskiwania (RTO) jest osiągalny.
Dokumentacja przełączania awaryjnego między regionami (failover). Trzy POPs (Frankfurt, Ashburn, Singapore) działają w trybie active-active dla przekierowań; audytor zapozna się z procedurą failover runbook oraz analizą post-mortem ostatniego zdarzenia regionalnego.

Confidentiality i Privacy – dołączane selektywnie#

Kategorie Confidentiality (poufność) i Privacy (prywatność) pokrywają się z wymogami GDPR. Większość klientów korporacyjnych w EU woli adresować kwestie prywatności poprzez dokumentację GDPR (umowy powierzenia przetwarzania danych zgodne z Artykułem 28, oceny skutków transferu danych, publiczne DPA) niż przez sekcję Privacy w SOC 2. Obecny zakres audytu SOC 2 dla Elido obejmuje Security, Availability oraz Confidentiality. Kwestie Privacy są adresowane oddzielnie poprzez zestaw dokumentacji GDPR dostępny pod adresem /trust.

Powód tego podziału jest prosty: SOC 2 Privacy mapuje się na AICPA Generally Accepted Privacy Principles, które zostały zaprojektowane dla ram prawnych US. GDPR to odrębny system prawny z własnymi mechanizmami kontrolnymi. Łączenie obu w jednym atestowaniu zazwyczaj osłabia wiarygodność obu tych obszarów.

Co HIPAA faktycznie mówi o skracaczu URL#

HIPAA – Health Insurance Portability and Accountability Act, zaktualizowany przez HITECH i 2013 Omnibus Rule – reguluje sposób postępowania z chronionymi informacjami zdrowotnymi (Protected Health Information – PHI) przez podmioty objęte ustawą (dostawcy opieki zdrowotnej, ubezpieczyciele, izby rozliczeniowe) oraz ich partnerów biznesowych (Business Associates).

Skracacz URL staje się partnerem biznesowym (Business Associate), gdy krótki link lub dane z nim powiązane niosą ze sobą PHI. Interesującym pytaniem jest, czy w ogóle dochodzi do takiej sytuacji – odpowiedź jest bardziej złożona, niż zakłada większość przeglądów zakupowych.

Kiedy PHI przepływa przez przekierowanie#

Sam krótki link – np. s.elido.me/abc123 – nie jest PHI. Docelowy adres URL, metadane obszaru roboczego i tagi kampanii również zazwyczaj nie stanowią PHI.

Kwestia PHI pojawia się w trzech konkretnych miejscach:

Docelowe adresy URL zawierające identyfikatory: krótki link przekierowujący do https://provider.example/patient/12345/results zawiera identyfikator pacjenta w ścieżce adresu URL. Ten docelowy URL jest przechowywany przez skracacz i w ścisłym znaczeniu stanowi PHI – nawet jeśli nikt w Elido nie interpretuje tego identyfikatora.
Niestandardowe parametry dodawane w momencie kliknięcia: jeśli przekierowanie dodaje identyfikator sesji lub użytkownika jako parametr URL i ten identyfikator można później powiązać z PHI, zdarzenie kliknięcia staje się częścią łańcucha PHI.
Zdarzenia kliknięcia z danymi o źródle (referrer): zdarzenie kliknięcia zawiera adres URL źródła. Jeśli źródło zawiera identyfikator pacjenta (np. strona portalu pacjenta z bezpośrednim linkiem, która skierowała użytkownika do skróconego linku), pole referrer stanowi PHI.

Większość marketingowych przypadków użycia w służbie zdrowia nie generuje PHI w żadnym z tych kanałów. Dział marketingu systemu opieki zdrowotnej prowadzący kampanie dotyczące szczepień przeciw grypie czy wydarzeń prozdrowotnych tworzy przekierowania z miejscami docelowymi i źródłami wolnymi od PHI. W takim scenariuszu BAA jest środkiem zapobiegawczym, a nie koniecznością architektoniczną.

Dla zadań, które faktycznie prowadzą do miejsc docelowych zawierających PHI – portali pacjenta, linków potwierdzających wizytę, adresów URL z wynikami badań – wymagane jest podpisanie BAA, a opisane poniżej mechanizmy kontrolne muszą zostać wdrożone po stronie skracacza.

HIPAA Security Rule zmapowane na usługę przekierowań#

HIPAA Security Rule (45 CFR Part 164, Subpart C) określa zabezpieczenia administracyjne, fizyczne i techniczne. Dla usługi przekierowań przetwarzającej PHI w adresach docelowych:

Access controls (Kontrola dostępu – 164.312(a)): unikalna identyfikacja użytkownika, automatyczne wylogowanie, szyfrowanie ePHI w transmisji i w spoczynku. Elido wymusza unikalne identyfikatory przypisane przez IdP, konfigurowalny czas wygaśnięcia sesji dla obszaru roboczego, TLS 1.3 dla wszystkich zewnętrznych punktów końcowych oraz szyfrowanie kopertowe AES-256 w spoczynku dla odpowiednich magazynów danych.
Audit controls (Kontrola audytu – 164.312(b)): rejestrowanie i badanie aktywności w systemach zawierających lub wykorzystujących ePHI. Elido generuje logi audytowe dla tworzenia linków, ich modyfikacji, zmian celu przekierowania oraz eksportu analityki do odpornego na manipulacje magazynu typu append-only. Domyślny czas retencji logów audytowych w planach Business+ wynosi 24 miesiące.
Integrity controls (Kontrola integralności – 164.312(c)): ochrona ePHI przed niewłaściwą zmianą. Docelowe adresy URL są przechowywane z historią na poziomie wiersza; każda modyfikacja jest logowana wraz z tożsamością wykonawcy i znacznikiem czasu, a poprzednia wartość pozostaje w tabeli historii.
Transmission security (Bezpieczeństwo transmisji – 164.312(e)): ochrona ePHI podczas transmisji w sieciach otwartych. TLS 1.3 na wszystkich punktach końcowych przekierowań; preloading HSTS; opcja przypinania certyfikatów (certificate pinning) dostępna dla domen niestandardowych.

Zabezpieczenia administracyjne i fizyczne (szkolenia personelu, polityki sankcji, kontrola dostępu do obiektów) w dużym stopniu pokrywają się z mechanizmami kontrolnymi SOC 2 Security. Te same dowody wspierają oba audyty, dlatego prowadzimy je według wspólnego harmonogramu.

Co obejmuje, a czego nie obejmuje BAA#

Business Associate Agreement (BAA) to umowa w rozumieniu HIPAA 164.504(e). Zobowiązuje ona partnera biznesowego do stosowania konkretnych zabezpieczeń, przestrzegania terminów powiadamiania o naruszeniach oraz przenoszenia zobowiązań na podwykonawców. BAA nie zmienia bazowej architektury; zobowiązuje dostawcę do zarządzania tą architekturą w sposób zgodny z HIPAA.

Standardowa umowa BAA oferowana przez Elido w planach Business i Enterprise obejmuje:

Cztery kategorie zabezpieczeń HIPAA Security Rule stosowane do wszystkich danych przekazywanych przez klienta przez usługę przekierowań.
Powiadomienie o naruszeniu w ciągu 60 dni od wykrycia, ze szczegółowymi terminami reagowania na incydenty opisanymi w BAA oraz w odpowiednim runbooku /docs/runbooks/incident-response.
Przeniesienie zobowiązań na wymienionych podwykonawców (Hetzner, OVH, Postmark, Cloudflare, monobank Plata) na podstawie ich własnych umów BAA, tam gdzie ma to zastosowanie. Aktualna lista podwykonawców znajduje się pod adresem /legal/subprocessors i jest to ta sama lista, która jest używana w dokumentacji GDPR Artykuł 28.
Zwrot lub zniszczenie PHI po zakończeniu umowy, z 30-dniowym oknem dla klienta na eksport danych przed ich usunięciem.

Czego BAA nie robi: nie sprawia, że plan niekwalifikujący się do HIPAA nagle staje się zgodny. Plany Free i Pro nie obejmują podpisania BAA. Infrastruktura jest taka sama we wszystkich płatnych planach; zobowiązania prawne – nie.

Ankieta zakupowa – odpowiedzi, które możesz skopiować#

Większość ankiet zakupowych w przedsiębiorstwach zawiera ten sam zestaw pytań. Poniższe odpowiedzi to te, których udzielamy bezpośrednio, wraz z linkami do odpowiednich dokumentów.

Czy posiadacie aktualny raport SOC 2 Type II? Posiadamy certyfikat ISO 27001; audyt SOC 2 Type II jest w toku, raport Type II planowany jest na czwarty kwartał 2026 r. Listy pomostowe (bridge letters) oraz aktualny certyfikat ISO 27001 są dostępne po podpisaniu NDA pod adresem /trust. Raport SOC 2 Type I został ukończony w listopadzie 2025 r. i jest również dostępny po podpisaniu NDA.

Czy podpiszecie nasze BAA? Podpisujemy nasze standardowe BAA w planach Business i Enterprise. Umowy BAA na wzorach klienta są analizowane w planie Enterprise; akceptujemy typowe modyfikacje (rozszerzone okna powiadomień o naruszeniach, dodatkowe atestacje zabezpieczeń, specyficzne dla klienta mechanizmy kontroli podwykonawców). Skontaktuj się z [email protected], aby otrzymać standardowy tekst lub rozpocząć analizę wzoru klienta.

Gdzie przechowywane są dane? Klienci z EU są domyślnie przypisani do Frankfurtu (Hetzner FRA1, region EU). Klienci z US mogą wybrać Ashburn (Hetzner ASH). Region Singapur (OVH SGP) jest dostępny dla klientów z APAC. Replikacja międzyregionowa jest opcjonalna dla każdego obszaru roboczego; bez niej wszystkie dane klienta pozostają w wybranym regionie. Wpis dotyczący rezydencji danych szczegółowo opisuje architekturę przechowywania.

Jakie szyfrowanie jest stosowane? TLS 1.3 w transmisji dla wszystkich zewnętrznych punktów końcowych (przekierowania, API, panel, analityka). Szyfrowanie kopertowe AES-256 w spoczynku dla bazy głównej Postgres, klastra ClickHouse oraz magazynu obiektowego. W planach Enterprise obsługiwany jest KMS dostarczony przez klienta poprzez integrację BYO KMS.

Jak odbywa się nadawanie i odbieranie uprawnień? Logowanie jednokrotne (SSO) przez SAML lub OIDC za pośrednictwem WorkOS; obsługa SCIM dla cyklu życia użytkownika. Kontrola dostępu oparta na rolach (RBAC) na poziomie obszaru roboczego, z możliwością tworzenia niestandardowych ról w planie Enterprise. Wpis o SCIM i SSO opisuje integrację i mechanizmy kontroli cyklu życia.

Jak wygląda proces reagowania na incydenty? Udokumentowany runbook z 60-minutowym SLA na pierwszą odpowiedź, 24-godzinnym SLA na aktualizację techniczną oraz rotacyjnymi dyżurami koordynatorów incydentów. Powiadomienia o naruszeniach następują zgodnie z terminami określonymi w BAA i DPA. Pełny indeks runbooków znajduje się pod adresem /docs/runbooks/.

Kim są wasi podwykonawcy? Pięciu wymienionych podwykonawców: Hetzner (infrastruktura, EU), OVH (infrastruktura, APAC), Postmark (e-maile transakcyjne), Cloudflare (ochrona DDoS publicznych powierzchni marketingowych; nie dotyczy warstwy danych przekierowań), monobank Plata (rozliczenia dla klientów z EU). Pełna lista z danymi kontaktowymi znajduje się pod adresem /legal/subprocessors.

Jak długo przechowujecie dane klientów? Zdarzenia kliknięć są przechowywane przez czas trwania umowy plus 30-dniowe okno na eksport po zakończeniu umowy, a następnie usuwane. Konfiguracja linków jest przechowywana przez czas trwania umowy plus okno na eksport. Zagregowane metryki (liczba linków w obszarze roboczym, liczba kliknięć dziennie, bez danych PII) są przechowywane po zakończeniu umowy na potrzeby rozliczeń i wewnętrznego planowania wydajności.

Plik z dowodami, którego potrzebuje audytor#

Jeśli jesteś klientem korporacyjnym prowadzącym własny audyt SOC 2 i Elido jest dostawcą objętym zakresem tego audytu, Twój audytor prawdopodobnie poprosi o dowody w ramach mechanizmów kontrolnych CC9.2 (zarządzanie dostawcami) i CC1.4 (zobowiązania). Plik dostawcy powinien zawierać:

Nasz aktualny certyfikat ISO 27001 (odnawiany corocznie).
Nasz raport SOC 2 Type I oraz list pomostowy (bridge letter) dla SOC 2 Type II (dostępne po podpisaniu NDA).
Podpisane umowy DPA oraz BAA, tam gdzie ma to zastosowanie.
Naszą listę podwykonawców wraz z datami wszelkich zmian.
Zrzut naszej publicznej strony bezpieczeństwa /trust oraz najnowszą wersję polityki prywatności.
Naszą historię powiadomień o naruszeniach (publiczna historia jest pusta – wewnętrzny log jest udostępniany do wglądu podczas procesu zakupowego po podpisaniu NDA).

Plik z dowodami jest przygotowywany raz przy rozpoczęciu współpracy i odświeżany co roku. Powyższa lista to standardowy zestaw; dodatkowe wymagania audytorów są rozpatrywane indywidualnie.

Co jest naprawdę trudne#

Dwie rzeczy są wyjątkowo trudne w kontekście SOC 2 i HIPAA dla usługi przekierowań. Wspominamy o nich, ponieważ zazwyczaj pojawiają się w rozmowach z działem zakupów.

Dowody na ciągłe monitorowanie POPs na brzegu sieci (edge) to wyzwanie. Warstwa danych przekierowań przetwarza ogromne wolumeny ruchu w trzech regionach, a audytor wymaga dowodów, że monitorowanie działa w sposób ciągły, a nie tylko wyrywkowy. Obecne podejście wykorzystuje syntetyczne przekierowania z każdego regionu co minutę, a stan alarmów jest zapisywany w odpornym na manipulacje logu. Koszt tego monitorowania jest realny, a jego projekt przeszedł trzy iteracje, aby uzyskać właściwy stosunek sygnału do szumu. Przewodnik po obserwowalności w dokumentacji opisuje aktualną konfigurację; bazowy dokument ADR znajduje się pod adresem /docs/adr/0024-sla-monitoring.md.

Terminy powiadamiania o naruszeniach w HIPAA są bardziej rygorystyczne niż w GDPR. HIPAA wymaga powiadomienia poszkodowanych osób w ciągu 60 dni od wykrycia; w przypadku naruszeń dotyczących ponad 500 osób wymagane są dodatkowe powiadomienia do HHS oraz mediów. GDPR daje 72 godziny na powiadomienie organu nadzorczego, ale termin powiadomienia osób, których dane dotyczą, jest określony jako „bez zbędnej zwłoki”. W przypadku naruszenia obejmującego wiele jurysdykcji, terminy HIPAA często stają się dominujące. Domyślnie zobowiązujemy się do przestrzegania terminów HIPAA dla każdego incydentu dotyczącego danych klientów kierowanych przez US, co znajduje odzwierciedlenie w naszym runbooku reagowania na incydenty.

Powiązane lektury#

GDPR dla skracaczy URL: co tak naprawdę chce zobaczyć Twój inspektor ochrony danych – fundament dla tematyki zgodności (compliance).
Rezydencja danych w EU dla analityki marketingowej – architektura rezydencji i opcje przypinania danych.
Schrems II a Twoje piksele śledzące – kontekst oceny skutków transferu danych.
SCIM i SSO dla narzędzi marketingowych – mechanizmy kontroli dostępu spełniające wymogi CC6.1.
Atrybucja kliknięć po Safari ITP – powiązany wpis o ograniczeniach prywatności po stronie przeglądarki.
Przewodnik operacyjny: przewodnik po dowodach SOC 2 w dokumentacji – jak w praktyce wygląda gromadzenie dowodów.
Oferta produktowa: /solutions/compliance oraz /solutions/enterprise w celu sprawdzenia dostępności funkcji w poszczególnych planach.