NIS2 a e-maile transakcyjne: Techniczna checklista dla zespołów IT

TL;DR

• NIS2 obejmuje również integrację e-mail. Art. 21 dyrektywy (UE) 2022/2555 wymaga m.in. szyfrowania, kontroli dostępu, MFA, obsługi incydentów i ciągłości działania. Każdy z tych obszarów dotyczy sposobu w jaki Twoja aplikacja wysyła e-maile.
• Kogo dotyczy: podmiotów kluczowych i ważnych z 18 sektorów, zwykle od 50 pracowników lub 10 mln euro obrotu. Ich dostawcy zostają objęci obowiązkami poprzez umowy.
• Co należy do zespołu IT: SPF, DKIM i DMARC na domenach nadawczych, TLS na każdym etapie, który kontrolujesz, klucze API poza kodem i regularnie rotowane, 2FA i ograniczenia IP w panelu dostawcy, logowanie zdarzeń doręczeń oraz plan na wypadek awarii.
• Terminy zgłoszeń: wczesne ostrzeżenie w ciągu 24 godzin od momentu, gdy dowiesz się o poważnym incydencie, zgłoszenie incydentu w ciągu 72 godzin i sprawozdanie końcowe w ciągu miesiąca. Wyciek danych logowania SMTP może uruchomić te ramy czasowe.
• Polska: znowelizowana ustawa o krajowym systemie cyberbezpieczeństwa (KSC) obowiązuje od 3 kwietnia 2026 r. Środki techniczne i organizacyjne trzeba wdrożyć do 3 kwietnia 2027 r.

Większość tekstów o NIS2 powstaje z myślą o działach compliance. Gdy jednak audytor zapyta jak firma zabezpiecza komunikację e-mail, odpowiedź zwykle leży w repozytorium kodu, strefie DNS i panelu dostawcy. To pytanie do zespołu IT.

Ten poradnik przekłada art. 21 na konkretne zadania dla zespołów, które utrzymują integrację e-maili transakcyjnych: resetów haseł, potwierdzeń zamówień, alertów i faktur. Znajdziesz tu skrót wymagań NIS2, środki, które dotyczą wysyłki, kroki zabezpieczające i plan działania na wypadek incydentu.

Jeśli wybierasz dostawcę komunikacji wielokanałowej (SMS, push, e-mail, RCS i OTT), sprawdź ten poradnik o NIS2 i bezpieczeństwie łańcucha dostaw.

NIS2 w pigułce

NIS2 (dyrektywa (UE) 2022/2555) zastąpiła pierwszą dyrektywę NIS i weszła w życie w styczniu 2023 r. Państwa członkowskie miały czas na jej wdrożenie do 17 października 2024 r. W Polsce odbyło się to poprzez nowelizację ustawy o KSC.

Dyrektywa dzieli objęte nią organizacje na dwie grupy:

• Podmioty kluczowe: m.in. energetyka, transport, bankowość, ochrona zdrowia, infrastruktura cyfrowa, administracja publiczna i sektor kosmiczny. Zwykle od 250 pracowników lub powyżej 50 mln euro obrotu.
• Podmioty ważne: m.in. usługi pocztowe i kurierskie, gospodarka odpadami, chemikalia, żywność, produkcja i dostawcy usług cyfrowych. Zwykle od 50 pracowników lub powyżej 10 mln euro obrotu.

Według szacunków Komisji Europejskiej NIS2 obejmuje ponad 160 tys. organizacji, wobec ok. 10 tys. za czasów NIS1. Jeśli Twoja firma jest poniżej progów, nie znaczy to jeszcze, że temat jej nie dotyczy. Gdy Twoi klienci podlegają NIS2, ich ocena dostawców najpewniej obejmie także Ciebie.

Kary (art. 34 dyrektywy) sięgają 10 mln euro lub 2% rocznego obrotu dla podmiotów kluczowych oraz 7 mln euro lub 1,4% dla podmiotów ważnych. Kierownictwo zatwierdza środki bezpieczeństwa, nadzoruje ich wdrożenie i może ponieść za nie odpowiedzialność (art. 20).

Harmonogram w Polsce według znowelizowanej ustawy o KSC:

Data	Co się dzieje
3 kwietnia 2026 r.	Znowelizowana ustawa o KSC wchodzi w życie.
12 czerwca 2026 r.	Podmioty mogą korzystać z systemu S46.
3 października 2026 r.	Mija termin samodzielnej rejestracji w wykazie podmiotów kluczowych i ważnych.
3 kwietnia 2027 r.	Środki techniczne i organizacyjne muszą być wdrożone, a podmioty korzystać z S46. Odtąd można nakładać kary za większość naruszeń.
3 kwietnia 2028 r.	Pierwszy audyt bezpieczeństwa informacji dla części podmiotów kluczowych.

Art. 21 a Twoja wysyłka e-mail

Siedem z dziesięciu środków z art. 21 ust. 2 przekłada się bezpośrednio na pracę przy integracji e-maili transakcyjnych. Pozostałe trzy (polityka analizy ryzyka, ocena skuteczności środków i szkolenia) zostają po stronie bezpieczeństwa i compliance.

Środek z art. 21 ust. 2	Co oznacza dla e-maili transakcyjnych	Jakie dowody zachować
lit. b) Obsługa incydentów	Wykrywanie nadużyć danych logowania, skoków wolumenu i błędów uwierzytelniania	Reguły alertów, logi zdarzeń, procedura reagowania
lit. c) Ciągłość działania i odtwarzanie po awarii	Krytyczne e-maile wychodzą dalej, albo działają w przewidywalnym trybie ograniczonym, podczas awarii dostawcy lub sieci	Projekt kolejki i ponowień, ścieżka zapasowa, wyniki testów przełączenia
lit. d) Bezpieczeństwo łańcucha dostaw	Dostawca e-mail to dostawca ICT, którego musisz ocenić	Certyfikaty dostawcy, umowa powierzenia przetwarzania danych, wypełniony kwestionariusz bezpieczeństwa
lit. e) Bezpieczeństwo przy nabywaniu, rozwijaniu i utrzymaniu systemów	Kod integracji, SDK i szablony przechodzą przez standardowy proces wytwarzania i obsługi podatności	Historia code review, skanowanie zależności
lit. h) Kryptografia i szyfrowanie	TLS przy wysyłce SMTP i wywołaniach API, zarządzanie kluczami DKIM	Konfiguracja TLS, długość kluczy DKIM i rejestr ich rotacji
lit. i) Kontrola dostępu i zarządzanie aktywami	Kto ma klucze API i dostęp do panelu, spis domen nadawczych i kluczy	Spis kluczy, przeglądy uprawnień, rejestr offboardingu
lit. j) MFA i zabezpieczona komunikacja	2FA w panelu dostawcy, uwierzytelnione e-maile	Polityka 2FA, opublikowana polityka DMARC

NIS2 nie wymienia z nazwy SPF, DKIM ani DMARC. Art. 21 wymaga zarządzania ryzykiem kanałów komunikacji, a te trzy standardy to powszechnie stosowana techniczna odpowiedź na podszywanie się pod domenę. Dlatego audytorzy zwykle o nie pytają.

Zabezpieczenie integracji e-mail: Pięć obszarów

Poniższe pięć obszarów pokrywa większość pytań audytora o konfigurację wysyłki. Każdy dostarcza też dowodów, które możesz zarchiwizować.

1. Uwierzytelnij każdą domenę nadawczą

• SPF: uwzględnij tylko usługi, które faktycznie wysyłają w Twoim imieniu i nie przekraczaj limitu 10 zapytań DNS.
• DKIM: używaj kluczy 2048-bitowych. Rotuj je według harmonogramu lub od razu gdy podejrzewasz wyciek.
• DMARC: zacznij od p=none z raportami zbiorczymi (rua). Przejdź na quarantine, a potem na reject gdy wszystkie właściwe źródła przechodzą weryfikację.
• Subdomeny: wysyłaj e-maile transakcyjne i marketingowe z osobnych subdomen. Incydent albo spadek reputacji na jednej nie przeniesie się wtedy na drugą.

mail.example.com.         TXT  “v=spf1 include:<your-provider-spf-domain> ~all”

_dmarc.mail.example.com.  TXT  “v=DMARC1; p=quarantine; rua=mailto:[email protected]; adkim=s; aspf=s”

2. Szyfruj każdy etap, który kontrolujesz

• Łącz się z API e-mail wyłącznie przez HTTPS.
• Przy SMTP wysyłaj przez port 587 z wymaganym STARTTLS albo przez port 465 z TLS od początku połączenia. Nie pozwól aplikacji wrócić do nieszyfrowanego połączenia. 
• Rozważ publikację MTA-STS i TLS-RPT dla swoich domen. MTA-STS wymusza TLS dla poczty przychodzącej do Ciebie, a TLS-RPT wysyła raporty, gdy doręczenie przez TLS się nie uda.
• Szyfruj przechowywane szablony i logi, które zawierają dane osobowe.

3. Traktuj dane logowania jak sekrety

• Trzymaj klucze API i hasła SMTP w menedżerze sekretów lub w sejfie CI. Nigdy w repozytorium ani w commitowanych plikach .env
• Generuj osobne klucze dla każdego środowiska i każdej usługi. Zmniejszy to zasięg potencjalnego wycieku, a jeden klucz unieważnisz bez stopowania całej wysyłki.
• Rotuj klucze według harmonogramu i zawsze, gdy odchodzi osoba z dostępem.
• Włącz 2FA dla każdego użytkownika panelu dostawcy i ogranicz dostęp do panelu i API do autoryzowanych adresów IP.
• Dodaj skanowanie sekretów do CI, aby wyłapać wycieknięte klucze zanim trafią na wspólną gałąź.
• Co najmniej raz na kwartał sprawdzaj kto ma uprawnienia do wysyłki produkcyjnej.

4. Loguj zdarzenia doręczeń i uważaj na anomalie

• Odbieraj webhooki dostawcy (doręczenie, odbicie, opóźnienie, zgłoszenie spamu) i przesyłaj je do centralnego systemu logów lub SIEM.
• Ustaw alerty na:
  • skoki wolumenu odbiegające od normy
  • wysyłkę z nieznanych adresów IP
  • nagły wzrost twardych odbić
  • nowe źródła w raportach zbiorczych DMARC
  • powtarzające się nieudane logowania do panelu
• Ustal okres przechowywania logów zgodny z polityką bezpieczeństwa i zasadą minimalizacji danych z RODO. Zwykle wystarczą odbiorca, znacznik czasu, status i identyfikator wiadomości.

5. Przygotuj się na awarię dostawcy lub sieci

• Kolejkuj wychodzące e-maile i ponawiaj wysyłkę z wykładniczo rosnącymi odstępami (exponential backoff). Używaj identyfikatorów wiadomości lub kluczy idempotencji, aby ponowienia nie tworzyły duplikatów.
• Krytyczne wiadomości (kody 2FA, resety haseł) puszczaj osobną kolejką, niezależną od masowych powiadomień.
• Dodaj circuit breaker i ścieżkę zapasową, np. alternatywny endpoint (API lub SMTP) albo drugiego dostawcę dla krytycznych wiadomości.
• Testuj przełączenie co najmniej raz w roku i zachowuj wyniki. To Twój dowód BCP/DRP dla art. 21 ust. 2 lit. c.

Wyciek klucza API i 24-godzinne okno

Wyciek danych logowania do usługi e-mail to jeden z bardziej prawdopodobnych powodów, dla których obowiązek zgłaszania incydentów z NIS2 trafi do zespołu IT. Wyobraź sobie produkcyjny klucz API wypchnięty do publicznego repozytorium. Po kilku godzinach ktoś używa go do wysyłki phishingu do Twoich klientów, z Twojej zweryfikowanej domeny.

To, czy incydent jest poważny, zależy od jego skutków (art. 23 ust. 3): poważnych zakłóceń działania, strat finansowych albo znacznych szkód dla innych. Phishing wysłany do klientów z Twojej domeny może spełnić ten próg. Przykładowa procedura:

1. Unieważnij klucz i wygeneruj nowy przez menedżer sekretów.
2. Wstrzymaj lub ogranicz wysyłkę z tego klucza albo domeny.
3. Przejrzyj logi: co wysłano, do kogo, z jakich adresów IP i od kiedy.
4. Od razu powiadom osobę odpowiedzialną za bezpieczeństwo. 24 godziny liczą się od momentu, w którym organizacja dowiedziała się o incydencie, a nie od zakończenia analizy.
5. Jeśli incydent jest poważny, przekaż właściwemu CSIRT-owi (dla większości firm prywatnych to CSIRT NASK) wczesne ostrzeżenie w ciągu 24 godzin, zgłoszenie incydentu w ciągu 72 godzin i sprawozdanie końcowe w ciągu miesiąca (art. 23 ust. 4).
6. Potem ustal jak klucz wyciekł, dodaj brakujące zabezpieczenie (skanowanie sekretów, węższy zakres klucza) i udokumentuj zmianę.

Jeśli wyciekły dane osobowe, sprawdź też czy musisz zgłosić naruszenie do UODO na podstawie RODO. Tam również obowiązuje termin 72 godzin.

Checklista NIS2 dla bezpieczeństwa e-mail

Lewa kolumna to praca po stronie Twojego zespołu. Prawa to to, co zbierasz od dostawcy e-mail.

Twoja integracja	Twój dostawca e-mail
☐ SPF, DKIM (2048 bitów) i DMARC w trybie egzekwowania na każdej domenie nadawczej	☐ Certyfikat ISO 27001 / SOC 2, aktualny i obejmujący usługi, z których korzystasz
☐ API i wysyłka SMTP wyłącznie przez TLS	☐ Obsługa TLS i szyfrowanie przechowywanych danych
☐ Klucze API w menedżerze sekretów, osobne dla środowisk, rotowane	☐ 2FA i ograniczenia IP dla panelu i API
☐ 2FA wymuszone dla każdego użytkownika panelu	☐ Przetwarzanie danych w EOG, ze wskazaniem konkretnych lokalizacji
☐ Webhooki doręczeń logowane centralnie, z alertami na anomalie	☐ Warunki powiadamiania o incydentach zgodne z Twoimi terminami 24/72 h
☐ Procedura reagowania na wyciek danych logowania	☐ SLA doręczeń i dokumentacja BCP/DRP
☐ Kolejka, ponowienia i ścieżka zapasowa dla krytycznych e-maili, z przetestowanym przełączeniem	☐ Podpisana umowa powierzenia przetwarzania danych (RODO)
☐ Spis domen nadawczych, kluczy i ich właścicieli	☐ Gotowość do wypełniania kwestionariuszy bezpieczeństwa i wsparcia przy audycie

Kilka praktycznych wskazówek przy zbieraniu dowodów od dostawcy:

• Sprawdź zakres certyfikatu. Powinien obejmować usługi, z których korzystasz, a nie tylko część działalności dostawcy.
• Pytaj o konkretne lokalizacje. Deklaracja „dane zostają w EOG” powinna iść w parze z nazwami krajów lub regionów.
• Wpisz terminy powiadomień do umowy. Twoje 24 godziny liczą się od wykrycia incydentu, a nie od chwili, gdy poinformuje Cię dostawca.

Jak EmailLabs pomaga przygotować się do NIS2

Część dowodów zapewnia dostawca platformy do wysyłki e-mail. Oto, co oferuje EmailLabs:

• Uwierzytelnianie nadawcy: konfiguracja SPF, DKIM i DMARC oraz obsługa BIMI.
• Szyfrowanie w transmisji: obsługa TLS przy doręczaniu wiadomości.
• Ochrona konta: 2FA przez SMS, aplikację mobilną lub klucz sprzętowy oraz autoryzacja IP, która ogranicza dostęp do zatwierdzonych adresów.
• Monitorowanie nadużyć: wykrywanie nietypowych wzorców wysyłki i nieautoryzowanego dostępu, z dynamicznymi progami i limitami wysyłki.
• Dedykowane adresy IP w pakietach Pro i Enterprise. Twoja reputacja nadawcy nie zależy wtedy od innych nadawców.
• Umowa powierzenia przetwarzania danych (RODO). Panel przechowuje tylko niezbędne dane: adresy nadawcy i odbiorcy oraz temat wiadomości.
• Certyfikat ISO 27001 / SOC 2. 
• Przetwarzanie danych wyłącznie w EOG, wewnątrz Niemiec i Polski.
• SLA dostępności lub doręczeń oraz testowane plany BCP/DRP.
• Typy zdarzeń w webhookach i przechowywanie logów.

Kolejne kroki: Trzy rzeczy na najbliższy kwartał

1. Zrób inwentaryzację. Spisz wszystkie domeny nadawcze, klucze API i dane logowania SMTP, usługi, które z nich korzystają, oraz ich właścicieli.
2. Uzupełnij luki. Przestaw DMARC na egzekwowanie, przenieś klucze do sejfu, włącz 2FA i ograniczenia IP, a webhooki doręczeń podłącz do systemu logów.
3. Zbierz dowody w jednym miejscu. Rekordy DNS, spis kluczy, reguły alertów, wyniki testów przełączenia, certyfikaty dostawcy i podpisaną umowę powierzenia przygotuj przed audytem, a nie w jego trakcie.

W Polsce środki z ustawy o KSC muszą zacząć działać przed 3 kwietnia 2027 r. Na naprawę tego co wyjdzie z inwentaryzacji zostało więc niespełna pół roku.

FAQ: NIS2 a bezpieczeństwo e-mail

Czy NIS2 wymaga DMARC?

Nie wprost. Art. 21 wymaga zarządzania ryzykiem kanałów komunikacji i zabezpieczonej komunikacji. SPF, DKIM i DMARC to powszechnie przyjęty techniczny sposób na spełnienie tego wymogu dla e-maili, więc audytorzy zwykle je sprawdzają.

Czy NIS2 wymaga TLS dla poczty e-mail?

Art. 21 ust. 2 lit. h wymaga polityk dotyczących kryptografii i szyfrowania. W praktyce oznacza to TLS dla danych w transmisji, w tym przy wysyłce SMTP i wywołaniach API dostawcy e-mail.

Czy mój dostawca usług e-mail podlega NIS2?

Zależy to od sektora i wielkości samego dostawcy. Dla Twojej firmy jest on tak czy inaczej dostawcą ICT, którego musisz ocenić na podstawie art. 21 ust. 2 lit. d.

Czy wyciek klucza API trzeba zgłosić jako incydent?

Tak, jeśli incydent jest poważny, czyli spowodował lub może spowodować poważne zakłócenia działania, straty finansowe albo znaczne szkody dla innych. Phishing wysłany do klientów z Twojej domeny może się więc kwalifikować.

Jakie są terminy zgłaszania incydentów w NIS2?

Wczesne ostrzeżenie w ciągu 24 godzin od momentu, gdy dowiesz się o poważnym incydencie, zgłoszenie incydentu w ciągu 72 godzin i sprawozdanie końcowe najpóźniej miesiąc po zgłoszeniu.

Od kiedy polskie firmy muszą spełniać wymagania NIS2?

Znowelizowana ustawa o KSC obowiązuje od 3 kwietnia 2026 r. Samodzielna rejestracja w wykazie zakończyła się 3 października 2026 r., a środki techniczne i organizacyjne trzeba wdrożyć do 3 kwietnia 2027 r.

Jakie kary grożą za brak zgodności z NIS2?

Dyrektywa przewiduje do 10 mln euro lub 2% rocznego obrotu dla podmiotów kluczowych i do 7 mln euro lub 1,4% dla podmiotów ważnych. Odpowiedzialność może ponieść także kierownictwo.