Rama: problem zaczyna się od zależności od vendora, nie od samego ataku.
Nota główna: Odpowiedzialność vendora EDM (case MyDr)
Do druku / memo: Checklista 72h (PDF)
0–4 h
- ☐ Potwierdź, czy korzystacie z danego dostawcy i w jakim module (EDM / terminarz / inne)
- ☐ Wyznacz ownera incydentu (IOD + IT/security + zarządzanie)
- ☐ Zamroź spekulacyjną komunikację zewnętrzną („nie wiemy jeszcze zakresu”)
4–24 h
- ☐ Pismo / ticket do procesora: zakres tenantów, kategorie danych, timeline, IOCs, rekomendacje
- ☐ Poproś o listę: czy Wasze ID klienta / baza jest w zakresie (tak / nie / nieustalone)
- ☐ Zabezpiecz logi własne (dostępy, integracje, eksporty)
24–72 h
- ☐ Udokumentuj ocenę ryzyka (dla Waszych osób / danych)
- ☐ Decyzja: zgłoszenie do UODO — tak / nie / wstępne + uzasadnienie
- ☐ Decyzja: zawiadomienie pacjentów — tak / nie / po doprecyzowaniu zakresu
- ☐ Przygotuj komunikat antyphishing (recepty, wizyty, „dopłaty”, kody BLIK)
- ☐ Sprawdź polisę cyber / obowiązki zgłoszenia do ubezpieczyciela
Równolegle (umowa i odporność)
- ☐ Umowa powierzenia: prawo audytu, SLA powiadomień, podprocesorzy, exit/eksport
- ☐ Lista innych vendorów z danymi wrażliwymi (top 10) — ten sam scenariusz „co jeśli jutro?”
5 pytań do vendora (wklej)
- Jaki jest potwierdzony zakres per nasz tenant?
- Jakie kategorie danych mogły zostać ujawnione?
- Od kiedy wiecie / od kiedy informujecie administratorów?
- Jakie działania containment już wykonano?
- Kiedy dostaniemy materiał do oceny ryzyka i zawiadomień?
Powiązane (klaster)
Stan szablonu: 21.08.2026 · nie stanowi porady prawnej.