O czym jest ten artykuł?
Szyfrowanie baz danych SQL w systemach ERP przestaje być wyłącznie zagadnieniem dla administratorów IT. W przedsiębiorstwach, które przechowują dane pracowników, klientów, kontrahentów czy informacje kadrowo-płacowe, sposób zabezpieczenia bazy danych może mieć bezpośrednie znaczenie dla realizacji obowiązków wynikających z RODO. Artykuł wyjaśnia, dlaczego szyfrowanie powinno być elementem szerszej strategii bezpieczeństwa oraz jak jego brak może zwiększać ryzyko biznesowe i regulacyjne.
Najważniejsze zagadnienia:
- szyfrowanie SQL a art. 32 RODO,
- bezpieczeństwo danych osobowych w systemach ERP,
- szyfrowanie danych „w spoczynku” i podczas transmisji,
- zarządzanie kluczami szyfrującymi,
- analiza ryzyka i zasada privacy by design,
- znaczenie kopii zapasowych i środowisk testowych,
- odpowiedzialność przedsiębiorstwa wobec UODO,
- wysokość kar za naruszenie bezpieczeństwa danych,
- praktyczna lista zabezpieczeń dla firm korzystających z ERP.
Spis treści
- Dlaczego baza ERP jest jednym z najważniejszych celów ochrony danych?
- RODO nie nakazuje szyfrowania każdej bazy SQL. Nakazuje jednak zarządzać ryzykiem
- Szyfrowanie SQL: gdzie naprawdę powstaje ochrona?
- Samo szyfrowanie nie wystarczy. UODO patrzy na cały system
- Kara od UODO może być znacznie droższa niż modernizacja ERP
- Jak przygotować bazę ERP do kontroli i incydentu?
- Szyfrowanie jako inwestycja w ciągłość biznesu
- Wnioski dla zarządów i dyrektorów finansowych
Dlaczego baza ERP jest jednym z najważniejszych celów ochrony danych?

System ERP jest cyfrowym centrum przedsiębiorstwa. W jednej bazie SQL mogą znajdować się informacje o pracownikach, klientach, dostawcach, wynagrodzeniach, numerach rachunków bankowych, adresach, historii transakcji czy rozliczeniach. W praktyce oznacza to, że przejęcie dostępu do bazy może mieć znacznie poważniejsze konsekwencje niż incydent dotyczący pojedynczego komputera.
Z perspektywy RODO kluczowe jest nie tylko to, czy firma posiada procedurę ochrony danych, ale czy zastosowane środki techniczne i organizacyjne rzeczywiście odpowiadają poziomowi ryzyka.
Dlatego przedsiębiorstwo powinno przede wszystkim:
- zidentyfikować dane osobowe przechowywane w ERP,
- określić, kto i w jakim zakresie może uzyskać do nich dostęp,
- ocenić ryzyko nieuprawnionego dostępu do bazy,
- zabezpieczyć bazę, kopie zapasowe oraz transmisję danych,
- regularnie testować skuteczność zabezpieczeń,
- dokumentować przyjęte rozwiązania i wyniki analizy ryzyka.
To istotne również dlatego, że w 2026 r. UODO nadal konsekwentnie podkreśla znaczenie odpowiednich środków technicznych, organizacyjnych oraz regularnego testowania ich skuteczności. W jednej z najnowszych decyzji dotyczących bezpieczeństwa danych organ wskazał m.in. na konieczność stosowania odpowiednich zabezpieczeń wynikających z analizy ryzyka.
RODO nie nakazuje szyfrowania każdej bazy SQL. Nakazuje jednak zarządzać ryzykiem
To jedno z najważniejszych rozróżnień, jakie powinien znać zarząd przedsiębiorstwa. RODO nie ustanawia zasady: „każda baza SQL musi być zaszyfrowana”. Art. 32 RODO wskazuje natomiast szyfrowanie i pseudonimizację jako przykładowe środki bezpieczeństwa, które należy uwzględnić odpowiednio do ryzyka.
Przy wyborze zabezpieczeń administrator powinien brać pod uwagę m.in.:
- stan wiedzy technicznej,
- koszt wdrożenia,
- charakter, zakres i cele przetwarzania,
- prawdopodobieństwo wystąpienia zagrożenia,
- potencjalną wagę skutków naruszenia,
- możliwość utraty, zmiany lub ujawnienia danych.
Art. 32 wymaga również zapewnienia poufności, integralności, dostępności i odporności systemów, możliwości odtworzenia danych po incydencie oraz regularnego testowania i oceniania skuteczności zabezpieczeń.
Wniosek jest ważny dla przedsiębiorców: brak szyfrowania nie oznacza automatycznie naruszenia RODO, ale brak adekwatnego zabezpieczenia danych może już stanowić poważny problem.
Jeżeli analiza ryzyka wykaże, że baza ERP zawiera szczególnie cenne lub szerokie zbiory danych, a jej przejęcie może powodować istotne konsekwencje dla osób fizycznych, szyfrowanie może stać się jednym z racjonalnych elementów wymaganej architektury bezpieczeństwa.
Szyfrowanie SQL: gdzie naprawdę powstaje ochrona?
Sformułowanie „zaszyfrowana baza danych” może oznaczać kilka różnych mechanizmów. Dla przedsiębiorstwa istotne jest więc ustalenie, co dokładnie jest szyfrowane, kiedy oraz kto posiada możliwość odszyfrowania danych.
Pierwszym poziomem jest szyfrowanie danych przechowywanych na serwerze, często określane jako encryption at rest. Chroni ono dane m.in. w przypadku kradzieży nośnika, nieuprawnionego dostępu do plików bazy lub określonych scenariuszy kompromitacji infrastruktury.
Drugim poziomem jest szyfrowanie transmisji między aplikacją ERP, serwerem SQL i innymi elementami infrastruktury. Ma ono ograniczać ryzyko przechwycenia danych podczas komunikacji.
Trzecim elementem są kopie zapasowe. Zabezpieczenie produkcyjnej bazy przy jednoczesnym przechowywaniu niezaszyfrowanego backupu na innym serwerze może stworzyć bardzo słabe ogniwo całego systemu.
W praktyce należy więc sprawdzić:
- czy szyfrowana jest baza produkcyjna,
- czy szyfrowane są backupy,
- czy szyfrowana jest komunikacja z serwerem SQL,
- gdzie przechowywane są klucze,
- kto ma dostęp do kluczy,
- czy klucze podlegają rotacji,
- czy dostęp administratorów jest rejestrowany,
- czy dane w środowisku testowym są odpowiednio zabezpieczone.
To ostatnie zagadnienie nabiera szczególnego znaczenia. UODO wskazywał, że przy systemach przetwarzających dane osobowe należy unikać wykorzystywania danych rzeczywistych w środowiskach testowych albo zapewnić im zabezpieczenia odpowiadające środowisku produkcyjnemu.
Samo szyfrowanie nie wystarczy. UODO patrzy na cały system
Szyfrowanie jest mocnym zabezpieczeniem, ale nie jest „polisą na RODO”. Firma może mieć zaszyfrowaną bazę SQL, a jednocześnie dopuścić do naruszenia poprzez słabe hasła, nadmierne uprawnienia, brak aktualizacji, źle skonfigurowany serwer lub niekontrolowane kopie danych.
Przykładowo pracownik może mieć dostęp do całej bazy, mimo że do wykonywania obowiązków potrzebuje tylko określonych rekordów. W takiej sytuacji szyfrowanie nie rozwiązuje problemu nadmiernych uprawnień użytkownika, który posiada legalny dostęp do systemu.
Dlatego architektura bezpieczeństwa ERP powinna obejmować co najmniej:
- zasadę najmniejszych uprawnień,
- wieloskładnikowe uwierzytelnianie tam, gdzie jest dostępne,
- segmentację infrastruktury,
- aktualizacje systemu operacyjnego i bazy,
- monitoring dostępu,
- rejestrowanie zdarzeń,
- szyfrowanie baz i kopii zapasowych,
- procedury reagowania na incydenty,
- regularne testy odtwarzania backupów,
- okresową analizę ryzyka.
Praktyka UODO pokazuje, że organ zwraca uwagę na całość zastosowanych zabezpieczeń. W 2023 r. urząd nałożył 30 tys. zł kary po incydencie ransomware, wskazując m.in. na niepełne środki techniczne i organizacyjne, nierzetelną analizę ryzyka oraz brak odpowiedniego podejścia do aktualizacji infrastruktury.
Kara od UODO może być znacznie droższa niż modernizacja ERP
Ryzyko związane z ochroną danych osobowych nie jest wyłącznie problemem działu IT. Jest to również ryzyko finansowe i zarządcze. RODO przewiduje administracyjne kary pieniężne, których wysokość może sięgać – zależnie od rodzaju naruszenia – 10 mln euro lub 2 proc. całkowitego rocznego światowego obrotu przedsiębiorstwa, a przy poważniejszych kategoriach naruszeń nawet 20 mln euro lub 4 proc. obrotu. Ostateczna wysokość kary zależy od okoliczności konkretnej sprawy.
UODO przy wymiarze kary bierze pod uwagę m.in. charakter i wagę naruszenia, liczbę osób, których dane dotyczą, rozmiar szkody, umyślność lub nieumyślność, działania ograniczające skutki incydentu oraz poziom zastosowanych środków technicznych i organizacyjnych.
Skala potencjalnego ryzyka jest widoczna w najnowszych decyzjach. W lutym 2026 r. UODO nałożył na DPD Polska kary o łącznej wartości ponad 11 mln zł, w tym ponad 5,2 mln zł za niewdrożenie odpowiednich środków organizacyjnych służących bezpieczeństwu danych.
Jeszcze bardziej wymowny jest przypadek opisany przez UODO w 2026 r., w którym łączna kara dla administratora i podmiotu przetwarzającego wyniosła blisko 5 mln zł oraz ponad 250 tys. zł. Postępowanie dotyczyło m.in. naruszenia obowiązków związanych z bezpieczeństwem przetwarzania i odpowiednimi środkami technicznymi oraz organizacyjnymi.
Nie oznacza to oczywiście, że brak szyfrowania SQL automatycznie prowadzi do wielomilionowej kary. Pokazuje jednak zmianę perspektywy: cyberbezpieczeństwo i ochrona danych stają się elementem zarządzania ryzykiem finansowym przedsiębiorstwa.
Jak przygotować bazę ERP do kontroli i incydentu?
Najlepszym momentem na ocenę bezpieczeństwa bazy danych jest okres przed wystąpieniem incydentu. Po ataku przedsiębiorstwo musi bowiem jednocześnie zabezpieczać infrastrukturę, analizować zakres naruszenia, podejmować decyzje dotyczące zgłoszenia i – w określonych przypadkach – informować osoby, których dane dotyczą.
Warto przeprowadzić audyt obejmujący:
- architekturę serwerów ERP i SQL,
- lokalizację baz danych,
- rodzaje przechowywanych danych osobowych,
- konta użytkowników i administratorów,
- mechanizmy szyfrowania,
- sposób zarządzania kluczami,
- backupy i ich lokalizację,
- środowiska testowe,
- logowanie i monitoring,
- proces aktualizacji,
- procedury reagowania na incydenty.
Istotne jest także udokumentowanie decyzji. Jeżeli przedsiębiorstwo uzna, że określony mechanizm szyfrowania nie jest potrzebny, powinno potrafić wykazać, z czego wynikała taka decyzja i jak przeprowadzono ocenę ryzyka.
UODO wielokrotnie zwraca uwagę, że nie wystarczy samo formalne posiadanie procedur. W jednym z postępowań urząd wskazał na znaczenie regularnego testowania, mierzenia i oceniania skuteczności środków bezpieczeństwa.
Szyfrowanie jako inwestycja w ciągłość biznesu

Argument za szyfrowaniem bazy ERP nie powinien ograniczać się do obawy przed karą administracyjną. Utrata kontroli nad bazą może oznaczać także przestój działalności, koszty obsługi incydentu, konieczność odtworzenia infrastruktury, utratę zaufania klientów oraz problemy z realizacją zobowiązań handlowych.
Szczególnie istotne jest rozdzielenie dwóch scenariuszy: kradzieży danych oraz zaszyfrowania danych przez ransomware. W pierwszym przypadku szyfrowanie może ograniczyć możliwość wykorzystania skradzionych danych w określonych scenariuszach. W drugim niezbędne są przede wszystkim odporność infrastruktury, bezpieczne kopie zapasowe i możliwość odtworzenia systemu.
UODO w sprawach dotyczących ransomware zwracał uwagę zarówno na zabezpieczenia techniczne, jak i na jakość analizy ryzyka oraz przygotowanie organizacji do incydentu.
Dlatego dojrzały model ochrony ERP powinien łączyć szyfrowanie z backupem, kontrolą dostępu, monitoringiem, aktualizacjami i testami odtwarzania.
Wnioski dla zarządów i dyrektorów finansowych
W 2026 r. pytanie „czy nasza baza SQL jest szyfrowana?” jest zbyt wąskie. Zarząd powinien pytać przede wszystkim: czy poziom ochrony danych w naszym systemie ERP jest adekwatny do ryzyka i czy potrafimy to udowodnić?
Szyfrowanie baz danych SQL może być jednym z najważniejszych elementów tej strategii. Nie zastępuje jednak analizy ryzyka, kontroli dostępu, aktualizacji, monitoringu ani sprawnych procedur reagowania na incydenty.
Dla przedsiębiorstwa oznacza to konieczność traktowania bezpieczeństwa ERP jako części zarządzania ryzykiem operacyjnym, prawnym i finansowym. Tym bardziej że aktualne decyzje UODO pokazują, iż konsekwencje niewdrożenia odpowiednich zabezpieczeń mogą być dla organizacji bardzo odczuwalne finansowo. W marcu 2026 r. NSA podtrzymał decyzję UODO dotyczącą Santander Bank Polska i kary 545 748 zł związanej m.in. z niewłaściwym postępowaniem po naruszeniu ochrony danych.
Najważniejsza zasada pozostaje więc prosta: szyfrowanie nie gwarantuje zgodności z RODO, ale w wielu środowiskach ERP może być istotnym elementem wykazania, że przedsiębiorstwo rzeczywiście podjęło adekwatne działania w celu ochrony danych osobowych.
W praktyce bezpieczeństwo powinno być projektowane warstwowo – od bazy SQL i kluczy szyfrujących, przez aplikację ERP i uprawnienia użytkowników, aż po backup, monitoring, procedury oraz regularne testy. To właśnie takie podejście pozwala ograniczyć nie tylko ryzyko kary UODO, ale przede wszystkim ryzyko biznesowych skutków incydentu.



























