4crypto.eu
Bezpłatna konsultacja
Kompetencja · Email security · 2026

Audyt bezpieczeństwa poczty w 2026 r. - SPF, DKIM, DMARC i całe ekosystem

Autor: dr inż. Adam CzubakCzas czytania: 12 minAktualizacja: 2026-05-13

Poczta elektroniczna to nadal wektor #1 ataków na organizacje. DBIR 2024 [1] wskazuje 68% naruszeń z komponentem ludzkim, z czego phishing dominuje. ENISA Threat Landscape 2024 [2] potwierdza: business email compromise (BEC) generuje miliardy euro strat rocznie w UE, znacznie więcej niż ransomware. Audyt bezpieczeństwa poczty sprawdza, na ile organizacja spowalnia lub blokuje ten wektor - od weryfikacji nadawcy (SPF/DKIM/DMARC) po szyfrowanie w transporcie (MTA-STS/TLS-RPT).

Artykuł porządkuje siedem RFC (7208 SPF [3], 6376 DKIM [4], 7489 DMARC [5], 8461 MTA-STS [6], 8460 TLS-RPT [7], 8617 ARC [8], 9091 BIMI [9]) tworzących ekosystem nowoczesnego email security, omawia drogę od polityki p=none do p=reject i pokazuje typowe błędy konfiguracji w polskich JST.

SPF - Sender Policy Framework

SPF [3] (RFC 7208, 2014) to mechanizm weryfikacji, czy serwer wysyłający pocztę jest autoryzowany przez domenę nadawcy. Działa przez wpis TXT w DNS:

`` domena.pl. IN TXT "v=spf1 ip4:1.2.3.4 include:_spf.google.com -all" ``

Składnia mówi: "Z domeny domena.pl mogą wysyłać pocztę tylko serwery z IP 1.2.3.4 lub te wskazane w rekordzie SPF Google. Wszystko inne - odrzuć (-all).". Odbierający serwer SMTP sprawdza pochodzenie ENVELOPE FROM (nie nagłówka From:!) i podejmuje decyzję.

Typowe błędy SPF wykryte podczas audytów (Foster et al. [10], Hu & Wang USENIX 2018 [11]):

  1. Brak SPF. Najgorszy stan - każdy może podszywać się pod domenę bez konsekwencji.
  2. Zbyt wiele include: - RFC 7208 ogranicza do 10 DNS lookupów. Większość polskich JST przekracza ten limit (Microsoft 365 + Google + 3-4 zewnętrzne mailingi → 12+ lookupów).
  3. +all lub ?all - "każdy może wysłać". Spotykane szokująco często.
  4. ~all zamiast -all - softfail zamiast hardfail. "Może być spam, ale dopuszczamy". Praktycznie SPF traci moc.
  5. Niezsynchronizowane From: z ENVELOPE FROM. SPF weryfikuje tylko envelope (Return-Path), nagłówek From: widoczny dla użytkownika może być inny. To rola DMARC, nie SPF.

DKIM - DomainKeys Identified Mail

DKIM [4] (RFC 6376, 2011) podpisuje wybrane nagłówki i ciało wiadomości kryptograficznie, kluczem prywatnym domeny. Klucz publiczny jest w DNS:

`` selector1._domainkey.domena.pl. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq..." ``

Każda wiadomość zawiera nagłówek DKIM-Signature z selektorem i podpisem. Odbiorca weryfikuje podpis kluczem publicznym z DNS. Jeśli pasuje → wiadomość dowodnie pochodzi z domeny i nie była modyfikowana w transporcie.

Typowe błędy DKIM:

  1. Brak DKIM - najczęstsze.
  2. Klucz RSA 1024 bit - przestarzały (NIST sugeruje 2048+ od 2014). Część dostawców (Gmail) coraz mocniej penalizuje DKIM 1024.
  3. Krótki body length tag (l=) - atakujący może doczepić dowolny content po podpisanej części.
  4. Brak rotacji kluczy DKIM - ten sam klucz przez 5+ lat. NIST sugeruje rotację co 6-12 miesięcy.

DMARC - łączenie SPF i DKIM z polityką

DMARC [5] (RFC 7489, 2015) to polityka egzekwowania - łączy SPF i DKIM i instruuje odbierające serwery, co robić z wiadomościami, które nie przejdą weryfikacji.

`` _dmarc.domena.pl. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@domena.pl; ruf=mailto:dmarc-forensic@domena.pl; pct=100; adkim=s; aspf=s" ``

Kluczowe pola:

  • p= (policy) - none (raportowanie tylko), quarantine (do spamu), reject (odrzuć).
  • rua= - adres do agregowanych raportów (codziennie XML z danymi).
  • ruf= - adres do forensic raportów (każdy nieudany SPF/DKIM).
  • pct= - procent wiadomości, do których stosujemy politykę (do stopniowego wdrażania).
  • adkim=/aspf= - s (strict, From: musi dokładnie pasować) lub r (relaxed, subdomeny OK).

Droga wdrożenia DMARC (najczęstsza rekomendacja):

  1. Etap 1 - p=none, pct=100 (4-6 tygodni). Tylko raportowanie. Analizujemy, kto wysyła w naszym imieniu (legalne usługi: Microsoft 365, Google, mailingowe, CRM, payroll).
  2. Etap 2 - p=quarantine, pct=10 → pct=100 (4-6 tygodni stopniowo). Część wiadomości do spamu. Obserwujemy raporty.
  3. Etap 3 - p=reject, pct=100. Wszystko, co nie ma poprawnego SPF lub DKIM z aligned From: jest odrzucane.

Foster et al. (znany jako [10] w naszej bibliografii - patrz nota) udokumentowali, że organizacje zatrzymujące się na p=none faktycznie nie zyskują ochrony - to tylko monitoring. Cel: p=reject w ciągu 3-6 miesięcy od startu.

MTA-STS, TLS-RPT, ARC, BIMI - nowsza warstwa

DMARC chroni autentyczność. Pozostają jednak problemy z transportem i łańcuchem dostarczania:

  • MTA-STS [6] (RFC 8461, 2018) - SMTP MTA Strict Transport Security. Polityka w HTTPS pliku /.well-known/mta-sts.txt, wymagająca, by każda przychodząca poczta używała TLS-a z zaufanym certyfikatem. Bez MTA-STS atakujący w MITM może wymusić downgrade TLS → cleartext. Stan w 2026 r.: Microsoft 365, Google, większość dużych dostawców obsługują. W polskich JST wdrożenie poniżej 20%.
  • TLS-RPT [7] (RFC 8460, 2018) - raportowanie problemów z TLS w transporcie. Pozwala wykryć, kiedy nasza poczta nie dochodzi z powodu błędu certyfikatu po stronie odbiorcy.
  • ARC [8] (RFC 8617, 2019) - Authenticated Received Chain. Rozwiązuje problem legitymego forwardingu (lista mailingowa zmienia wiadomość, łamie DKIM). ARC zachowuje informację o autentyczności przez każdego pośrednika.
  • BIMI [9] (RFC 9091, 2021, eksperymentalny) - Brand Indicators for Message Identification. Wymaga p=quarantine lub p=reject DMARC. Pozwala wyświetlać logo firmy obok wiadomości w klientach pocztowych (Gmail, Apple Mail, Yahoo). To marketingowa nagroda za dojrzałą politykę DMARC.

Stan typowej polskiej JST 2026 r. według naszych audytów:

  • SPF: skonfigurowany, ale 65% ma błędy (zbyt wiele lookupów, ~all zamiast -all).
  • DKIM: skonfigurowany w 60% przypadków, w 40% klucz 1024 bit.
  • DMARC: skonfigurowany w 40%, z czego 85% pozostaje na p=none.
  • MTA-STS: < 15% wdrożeń.
  • TLS-RPT: < 10%.
  • ARC: < 5%.
  • BIMI: < 1% (głównie tylko duże firmy prywatne).

Co audytujemy

Pełny audyt poczty obejmuje:

  1. DNS records - SPF (składnia, limit lookupów, polityka), DKIM (selektory, klucze, ich długość), DMARC (polityka, alignment, raportowanie), MTA-STS, TLS-RPT, ARC sender configuration, BIMI (jeśli zastosowane).
  2. Konfiguracja serwera pocztowego - Postfix/Exchange/Microsoft 365/Google Workspace. Wyłączenie open relay, wymuszenie TLS 1.2+, MFA dla wszystkich kont, audytowanie automatycznego forwardingu (typowy wektor BEC), rate limiting, sender reputation.
  3. Bramę antyspamową/antyphishingową - reguły, threat intelligence, sandbox dla załączników, URL rewriting (np. Microsoft Safe Links).
  4. Polityka adresowa i SSO - czy istnieją osoby z firstname.lastname@, czy alias pattern jest przewidywalny dla atakujących. MFA dla wszystkich kont z dostępem do skrzynek.
  5. Procedury i szkolenia - DLP, klasyfikacja informacji w mailu, procedura zgłaszania phishingu (one-click reporting w Outlook/Gmail). Zob. Security Awareness.
  6. Monitoring - alerty na masową rejestrację adresów (ang. potencjalne takeover), nietypowe forwarding rules, podejrzane aktywności w Microsoft 365 Audit Log.

Najczęstsze błędy

  1. DMARC p=none na zawsze. "Boi nas wycinanie legalnych wiadomości". Bez planu eskalacji to brak ochrony.
  2. SPF flat zamiast hierarchii. Zbyt wiele include: w jednym rekordzie → przekroczenie limitu 10 lookupów → niektóre poprawne wiadomości fail SPF.
  3. DKIM klucz 1024 bit od 2015 r. Bez rotacji.
  4. Brak monitoringu raportów DMARC. rua= skonfigurowany, ale nikt nie czyta tych XML-i. Narzędzia: dmarcian, EasyDMARC, Valimail, Postmark - niektóre darmowe dla małych domen.
  5. From: z innej domeny niż infrastruktura. Marketing wysyła z @klient-domena.pl przez Mailchimp, ale Mailchimp nie ma DKIM dla tej domeny → DMARC fail.
  6. Brak BIMI mimo p=reject. Pomija marketing-bonusowy aspekt (logo widoczne w skrzynce).
  7. MTA-STS w trybie testing zamiast enforce. Po 6 miesiącach testu - przejście do enforce jest pomijane.

Regulacje wymagające zabezpieczenia poczty

  • NIS2 art. 21 (1) lit. h [12] - "podstawowe procedury cyberhigieny i szkolenie personelu" - implikuje konfigurację SPF/DKIM/DMARC.
  • RODO art. 32 [13] - "odpowiednie środki techniczne i organizacyjne" - utrata danych przez phishing jest standardowym przypadkiem.
  • DORA art. 8-9 [14] - wymóg ochrony przed atakami cyber.
  • KSC art. 11 [15] - wymóg ochrony systemów operatorów usług kluczowych.
  • PUODO w raporcie rocznym [16] wskazuje BEC i phishing jako najczęstsze naruszenia danych.

Trendy 2025-2027

  1. PQC (post-quantum) DKIM. Aktualne klucze RSA i ECDSA staną się podatne na komputery kwantowe. Praca w IETF nad rozszerzeniem DKIM o post-quantum signatures.
  2. Stronger BIMI adoption. Gmail i Yahoo dodały (2023-2024) wymóg DMARC p=reject jako warunek do dostarczania masowych wiadomości (>5000 dziennie). Marketing wymusza dojrzałość.
  3. Generative AI phishing. ChatGPT-class narzędzia generują phishing nieodróżnialny od legitymego. Defense: kryptograficzna weryfikacja (DMARC + ARC) staje się jeszcze ważniejsza, "uważne czytanie wiadomości" przestaje wystarczyć.

Checklist: 10 punktów audytu poczty

Może być wykonany w pół godziny dla małej domeny - wystarczą tools online (mxtoolbox, dmarcian, mail-tester).

  1. SPF. Składnia poprawna, max 10 DNS lookupów, polityka -all (nie ~all/?all), brak zewnętrznych domen bez kontroli.
  2. DKIM. Skonfigurowany, klucz min. 2048 bit, rotacja udokumentowana (raz na 6-12 mies.), wszystkie strumienie wysyłki podpisywane.
  3. DMARC. Polityka p=quarantine lub p=reject (nie p=none), rua= skonfigurowany i czytany, adkim=s, aspf=s dla maksymalnej ochrony.
  4. Monitoring raportów DMARC. Narzędzie do analizy (dmarcian, EasyDMARC, własny parser) z przeglądem min. tygodniowym.
  5. MTA-STS. Polityka skonfigurowana w trybie enforce (nie testing), publikowana via HTTPS, ważny certyfikat.
  6. TLS-RPT. Raportowanie aktywne, raporty czytane min. miesięcznie.
  7. Konfiguracja serwera. Brak open relay, TLS 1.2+ wymuszone, MFA dla wszystkich kont, monitoring forwarding rules.
  8. Antyspam/antyphishing. Brama z TI feed, sandbox załączników, URL rewriting/safe links, DLP.
  9. Polityka adresowa. Brak ujawnionych aliasów strukturalnych (firstname.lastname@), MFA dla executive accounts.
  10. Awareness. Pracownicy wiedzą, jak zgłaszać phishing (one-click report), symulacje minimum kwartalnie. Zob. Security Awareness.

Najczęściej zadawane pytania

Ile trwa droga od p=none do p=reject?

Dla średniej JST z 1-3 strumieniami wysyłki: 3-6 miesięcy. Dla dużej organizacji z 10+ usługami marketingowo-transakcyjnymi: 6-12 miesięcy. Spieszenie się grozi odrzuceniem legalnych wiadomości (zwłaszcza od dostawców zewnętrznych) - strata operacyjna większa niż korzyść z DMARC.

Co zrobić, gdy zewnętrzny dostawca (CRM, mailing) nie wspiera DKIM dla naszej domeny?

Alternatywy: 1) zmień dostawcę, 2) wyślij z subdomeny (np. mail.domena.pl) z osobną polityką DMARC, 3) dołącz dostawcę do SPF include (jeśli wspiera) i licz tylko na SPF alignment dla tego strumienia. Praktycznie: nowoczesny CRM (HubSpot, Salesforce, Mailchimp, ActiveCampaign) wspiera DKIM.

Czy MTA-STS wymaga klienta poprawiającego coś po stronie odbierającej?

MTA-STS to polityka odbiorcy - mówi, jak inni mają wysyłać do nas. Wdrożenie po naszej stronie chroni naszą pocztę przychodzącą. Wysyłanie do innych w TLS musi być wymuszone konfiguracją MTA (ang. smtp_tls_security_level=verify w Postfix, Strict TLS w Exchange).

Czy BIMI jest opłacalne dla JST?

Marketingowo - tak, choć efekt subtelny. Wymaga: 1) p=reject DMARC, 2) SVG-T logo, 3) opcjonalnie VMC (Verified Mark Certificate, kosztuje ok. 1500 USD/rok) dla najlepszej widoczności w Gmail/Apple. Dla JST priorytet jest niższy niż dla brandu komercyjnego.

Czy mogę używać darmowych narzędzi typu mail-tester?

Tak - to dobry pierwszy test. Dla pełnego audytu potrzeba narzędzia analizującego raporty DMARC w czasie (dmarcian, EasyDMARC, Postmark - wersje darmowe wystarczają dla małych domen). Plus manualna weryfikacja konfiguracji serwerów.

Co z forwarding rules - to wektor BEC?

Tak. Mailbox rules forward to external to klasyczny wektor business email compromise. Atakujący przejmuje konto, dodaje regułę przekazującą poufne wiadomości na zewnątrz. Monitoring (Microsoft 365 Audit Log + alert SOC) i polityka domyślnie blokująca external forwarding to standard 2026 r.

Czy DMARC chroni przed phishingiem typu cousin domain (np. faktura-domena.pl)?

Nie. DMARC [5] chroni tylko dokładną domenę. Phishing z cousin domain wymaga: monitoringu rejestracji podobnych nazw (np. URLhaus, OpenPhish, DomainTools), polityki defensive registration (rejestrujemy sami typowe wariacje) i - krytycznie - szkolenia użytkowników (zob. Security Awareness).

Mam tysiące XML raportów DMARC - jak je przerobić ręcznie?

Nie ręcznie. RFC 7489 [5] sekcja 7.2 definiuje format XML agregowanych raportów - ale praktycznie wszyscy używają narzędzi:

  • Darmowe / open source: parsedmarc, dmarc-visualizer, DMARC Analyzer (darmowa wersja dla małych domen).
  • Komercyjne: dmarcian, EasyDMARC, Valimail, Postmark DMARC Digests, Red Sift OnDMARC.
  • Własny stack: Elastic Stack + Logstash filter dla DMARC XML + Kibana dashboard.

Wybór zależy od wolumenu (małe domeny < 50 raportów/dziennie - wystarczy darmowe; duże podmioty - komercyjny z dedykowanym alerting i thread intel).

Mój ESP (Mailchimp, HubSpot) prosi o przejście z p=reject na p=none - czy to bezpieczne?

Nie. Powszechny błąd na forach - ESP zrzuca problem dostarczalności na klienta. Właściwe rozwiązanie:

  1. Dodaj ESP do DKIM dla swojej domeny - większość ESP wspiera (Mailchimp wymaga rekordów DKIM-2 i DKIM-1, HubSpot wymaga _hubspot.domena.pl itp.).
  2. Dodaj ESP do SPF [3] - jeśli mieści się w limicie 10 lookupów.
  3. Lub: wysyłaj z subdomeny (np. mail.domena.pl) z osobną polityką DMARC p=none dla tej subdomeny, ale utrzymuj p=reject dla głównej.

RFC 7489 [5] sekcja 6.7 dopuszcza różne polityki dla różnych subdomen - to standardowe rozwiązanie problemu. Nie ma technicznej konieczności obniżania polityki głównej.

Forwarding wewnątrz organizacji łamie DMARC - jak zachować autentyczność?

ARC (Authenticated Received Chain) [8] (RFC 8617, 2019) został zaprojektowany dokładnie do tego. Każdy pośrednik w łańcuchu (np. lista mailingowa, reguła auto-forward) podpisuje swoją weryfikację SPF/DKIM i przekazuje dalej. Odbiorca może wtedy zaufać łańcuchowi mimo łamania oryginalnego DKIM/SPF.

Stan adopcji 2026 r.: Gmail, Microsoft 365, Yahoo, Mimecast, Proofpoint - wszyscy implementują ARC po stronie odbiorcy. Po stronie nadawcy/pośrednika - Microsoft 365 i Google Workspace generują nagłówki ARC automatycznie. Sprawdź swoją bramę pocztową (Postfix wymaga modułu OpenARC lub komercyjnego).

Co to jest DKIM rotation i jak często?

DKIM rotation = wymiana pary kluczy DKIM (prywatny + publiczny w DNS) na nową. Powody:

  • Kompromitacja klucza prywatnego (kradzież, leak konfiguracji).
  • Algorithm upgrade (z RSA 1024 → 2048, z RSA → Ed25519).
  • Higiena kryptograficzna - NIST SP 800-57 zaleca rotację kluczy podpisujących co 1-3 lata w zależności od skali użycia.

Praktyka:

  1. Dodaj nowy selektor (np. selector2._domainkey.domena.pl) z nowym kluczem publicznym przed zmianą u dostawcy/serwera.
  2. Przełącz wysyłkę na nowy selektor.
  3. Pozostaw stary selektor w DNS przez 1-2 tygodnie (wiadomości w tranzycie nadal podpisane starym kluczem).
  4. Usuń stary rekord DNS po okresie przejściowym.

Microsoft 365 i Google Workspace mają automatyczną rotację (Microsoft co ~6 mies., Google konfigurowalna). Własne servery wymagają manualnej procedury.

Czy BIMI zwiększa konwersję w mailingu?

Tak, ale efekt zależy od klienta pocztowego. RFC 9091 [9] (BIMI, eksperymentalny, 2021) pozwala wyświetlać logo nadawcy obok wiadomości. Wsparcie 2026 r.:

  • Gmail: pełne, wymaga VMC (~1500 USD/rok od DigiCert/Entrust) lub CMC (Common Mark Certificate, tańszy).
  • Apple Mail (iOS 16+): pełne wsparcie BIMI.
  • Yahoo Mail: tak.
  • Microsoft Outlook.com / Outlook Desktop: częściowe, dopiero w 2024-2025 zaczynają adopcję.

Badania marketingowe (Validity, Mailchimp): wzrost CTR (ang. click-through rate) o 10-20% w kampaniach z BIMI vs. bez. Warunek konieczny: DMARC p=quarantine lub p=reject + SVG-T zgodne ze specyfikacją RFC 9091.

Potrzebujesz konsultacji w tym obszarze?

Bezpłatna 30-60 minutowa konsultacja. Bez zobowiązań. Omawiamy potrzeby, skalę i ramowy harmonogram.

Zadzwoń: +48 691 122 312office@4crypto.eu

Powiązane treści

Pozostałe obszary kompetencyjne

Bibliografia i źródła

Wszystkie cytowane źródła są publicznie dostępne. Standardy ISO/IEC, RFC IETF, dyrektywy UE i akty krajowe odsyłają do oryginalnych dokumentów.

  1. [1]reportVerizon Business (2024). 2024 Data Breach Investigations Report (DBIR). Verizon, 17th edition · https://www.verizon.com/business/resources/reports/dbir/
  2. [2]reportEuropean Union Agency for Cybersecurity (ENISA) (2024). ENISA Threat Landscape 2024. ENISA, Heraklion · DOI: 10.2824/0710888
  3. [3]rfcKitterman, S. (2014). RFC 7208: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1. IETF · https://datatracker.ietf.org/doc/html/rfc7208
  4. [4]rfcCrocker, D., Hansen, T., Kucherawy, M. (Ed.) (2011). RFC 6376: DomainKeys Identified Mail (DKIM) Signatures. IETF · https://datatracker.ietf.org/doc/html/rfc6376
  5. [5]rfcKucherawy, M., Zwicky, E. (Eds.) (2015). RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC). IETF · https://datatracker.ietf.org/doc/html/rfc7489
  6. [6]rfcMargolis, D., Risher, M., Ramakrishnan, B., Brotman, A., Jones, J. (2018). RFC 8461: SMTP MTA Strict Transport Security (MTA-STS). IETF · https://datatracker.ietf.org/doc/html/rfc8461
  7. [7]rfcMargolis, D., Brotman, A., Ramakrishnan, B., Jones, J., Risher, M. (2018). RFC 8460: SMTP TLS Reporting (TLS-RPT). IETF · https://datatracker.ietf.org/doc/html/rfc8460
  8. [8]rfcAndersen, K., Long, B. (Ed.), Blank, S. (Ed.), Kucherawy, M. (Ed.) (2019). RFC 8617: The Authenticated Received Chain (ARC) Protocol. IETF · https://datatracker.ietf.org/doc/html/rfc8617
  9. [9]rfcBrotman, A., Adams, T. (2021). RFC 9091: Experimental Brand Indicators for Message Identification (BIMI). IETF · https://datatracker.ietf.org/doc/html/rfc9091
  10. [10]peer-reviewedFoster, I. D., Larson, J., Masich, M., Snoeren, A. C., Savage, S., Levchenko, K. (2015). Security by Any Other Name: On the Effectiveness of Provider Based Email Security. Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security (CCS '15), pp. 450-464 · DOI: 10.1145/2810103.2813607
  11. [11]peer-reviewedHu, H., Wang, G. (2018). End-to-End Measurements of Email Spoofing Attacks. Proceedings of the 27th USENIX Security Symposium, pp. 1095-1112 · https://www.usenix.org/conference/usenixsecurity18/presentation/hu
  12. [12]regulationParlament Europejski, Rada UE (2022). Dyrektywa (UE) 2022/2555 (NIS2) w sprawie środków na rzecz wysokiego wspólnego poziomu cyberbezpieczeństwa. Dziennik Urzędowy UE, L 333, 27.12.2022 · https://eur-lex.europa.eu/legal-content/PL/TXT/?uri=CELEX:32022L2555
  13. [13]regulationParlament Europejski, Rada UE (2016). Rozporządzenie (UE) 2016/679 (RODO) w sprawie ochrony osób fizycznych w związku z przetwarzaniem danych osobowych. Dziennik Urzędowy UE, L 119, 4.5.2016 · https://eur-lex.europa.eu/legal-content/PL/TXT/?uri=CELEX:32016R0679
  14. [14]regulationParlament Europejski, Rada UE (2022). Rozporządzenie (UE) 2022/2554 (DORA) w sprawie operacyjnej odporności cyfrowej sektora finansowego. Dziennik Urzędowy UE, L 333, 27.12.2022 · https://eur-lex.europa.eu/legal-content/PL/TXT/?uri=CELEX:32022R2554
  15. [15]regulationSejm RP (2018). Ustawa z dnia 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa (KSC). Dz.U. 2018 poz. 1560 (z późn. zm.) · https://isap.sejm.gov.pl/isap.nsf/DocDetails.xsp?id=WDU20180001560
  16. [16]reportPrezes UODO (2024). Sprawozdanie roczne z działalności Prezesa UODO za 2023 r.. UODO, Warszawa · https://uodo.gov.pl/pl/138/3270