TL;DR
On 5 October 2026 the President of UODO published guidance on the Article 33(1) notification threshold, following a series of incidents involving unauthorised access to contractor databases and invoicing systems. If only entrepreneurs' data already public in the CEIDG register were exposed (name, business name, NIP tax number, official address), risk is normally unlikely and notification may not be needed. If the PESEL number, purchase details revealing health or other special categories, or financial information leaked alongside them, notification is due; with high risk, data subjects must be told as well (Article 34). Always: a documented risk assessment and the reasons for not notifying in the internal register.
The context
In the latest incidents reported in Poland, attackers did not reach consumer customer files but contractor databases and invoicing systems: lists of businesses and professionals an organisation works with. UODO asks every controller for a serious, case-by-case risk assessment whose result determines whether notification is due.
When notification may not be needed
The typical case is sole traders whose exposed data match what anyone can look up in the public CEIDG register: first and last name, business name, NIP, official business address. According to the authority, loss of confidentiality of such data does not, as a rule, give the recipient new ways of harming the person concerned. Other countries have equivalent public business registers, but the assessment must always be made on the actual case.
When it is due
- PESEL, the Polish national identification number: risk of identity theft, fraud and debts taken out in the person's name.
- DETAILS OF PURCHASES OR SERVICES revealing health or other special categories: risk to privacy, discrimination, unauthorised profiling.
- FINANCIAL INFORMATION: risk of fraud and of fake invoices or payments.
Not notifying does not mean not documenting
Even when a controller concludes that notification is not needed, it must still carry out and document the risk assessment and record in the internal breach register the grounds for not notifying. The GDPR requires all breaches to be documented, notified or not (Article 33(5)). A decision not to notify that leaves no written trace cannot be defended in an inspection.
What it means for the DPO
Five moves for an incident in the invoicing system
One: reconstruct exactly which fields were exposed, record by record, rather than reasoning about «the database» in the abstract. Two: separate data that are already public from everything else (IBANs, amounts, service descriptions, personal contact details, notes). Three: write the assessment down with date, author, criteria and conclusion, and reopen it if new facts emerge. Four: watch the 72 hours, which run from awareness of the breach, not from the end of the analysis. Five: if the incident happened at a vendor, check that it informed the controller without undue delay (Article 33(2)) and that the contract requires it.
UODO's reading is consistent with EDPB Guidelines 9/2022 on breach notification: the threshold is not how serious the incident feels but the risk to people. The practical value of the Polish guidance lies in its examples, which show what turns a contractor list into a notifiable problem.
Looking for a workspace for your DPO work?
DPO Workspace is built by a certified DPO. 30-day free trial.
Start free
