The GDPR in 2026: principles, rights, DPIA, breaches and data transfers

What the GDPR is - origins and structure

The predecessor of the GDPR was Directive 95/46/EC. After two decades, the European Commission identified three structural problems. First, fragmentation: every Member State had its own implementing law and differences created a patchwork for organisations operating across borders. Second, the directive pre-dated the modern cloud and global data economy. Third, sanctions in many Member States were too weak to materially influence business decisions.

The answer was a regulation rather than another directive. The GDPR is directly applicable and does not need to be transposed. Member States retain limited room to regulate matters expressly left to national law, including some employment processing and procedural questions.

The GDPR contains 99 articles in eleven chapters and 173 recitals. Chapter I contains general provisions and definitions; Chapter II sets out processing principles and legal bases; Chapter III establishes data-subject rights; Chapter IV regulates controllers and processors. Chapter V governs transfers outside the EEA, Chapters VI and VII supervisory authorities and cooperation, Chapter VIII remedies and sanctions, and Chapter IX specific processing situations such as journalism, archiving and scientific research. Recitals do not create stand-alone duties, but they help interpret the operative provisions and are regularly used by supervisory authorities and courts.

The Polish Act of 10 May 2018 on personal data protection^[2] does not transpose the GDPR. It establishes the President of the Personal Data Protection Office (UODO) as the supervisory authority, sets national procedural rules, contains criminal provisions for selected conduct and regulates matters left to domestic law. Poland did not lower the Article 8 age for a child's consent to information-society services, so the default GDPR threshold of 16 applies where processing is based on consent and the service is offered directly to the child.

Territorial and material scope

Article 3 uses two independent connecting factors, explained further in EDPB Guidelines 3/2018^[8]. The first is establishment: the GDPR applies to processing in the context of the activities of an establishment of a controller or processor in the Union, regardless of where the processing itself takes place. A Polish company using a US data centre does not leave the GDPR merely because the servers are abroad.

The second is targeting. The GDPR also applies to certain controllers and processors without an EU establishment when they process data of people who are in the Union in connection with offering them goods or services, whether payment is required or not, or monitoring their behaviour in the Union. Behavioural analytics, advertising tracking and profiling can therefore trigger Article 3(2) even when the provider makes no sales in Europe.

An organisation outside the Union covered by Article 3(2) must generally designate an EU representative under Article 27, unless one of the narrow statutory exceptions applies. The representative acts as a contact point for supervisory authorities and data subjects; appointment does not transfer the substantive responsibility of the controller or processor.

The material scope covers automated processing and non-automated processing where the data form, or are intended to form, part of a filing system. The exclusions are narrow: activities outside the scope of Union law, parts of the common foreign and security policy, purely personal or household activity, and processing by competent authorities for law-enforcement purposes, which is governed by Directive (EU) 2016/680.

At the centre of the regulation is Article 4(1): personal data are any information relating to an identified or identifiable natural person. The definition is intentionally broad. It can include names and national identifiers, but also IP addresses, cookie identifiers and location data where identification is reasonably possible in context.

A particularly important distinction is between anonymisation and pseudonymisation. Properly anonymised information falls outside the GDPR only when the person is no longer identifiable taking account of the means reasonably likely to be used. Pseudonymised data remain personal data because additional information can restore the link to an individual. Pseudonymisation is therefore a security and privacy measure, not a way to escape the regulation. ENISA discusses techniques and limitations in its guidance.^[9]

Processing principles - Article 5

Article 5 contains six substantive principles plus accountability. These are enforceable legal requirements, not general aspirations, and each can be an independent basis for a supervisory decision.

Lawfulness, fairness and transparency require a valid legal basis under Article 6, fair treatment of the individual and understandable information about processing. Purpose limitation means data are collected for specified, explicit and legitimate purposes and are not later used incompatibly with those purposes. Data minimisation limits collection to what is adequate, relevant and necessary. A recruitment form, for example, should not collect information simply because it might be interesting to the employer.

Accuracy requires reasonable steps to keep data correct and up to date where necessary. Storage limitation requires deletion or anonymisation when the relevant purpose no longer justifies keeping identifiable data, subject to other legal duties. Integrity and confidentiality form the core security principle and are developed further in Article 32.

Accountability in Article 5(2) changes how the other principles operate. The controller is responsible for compliance and must be able to demonstrate it. Records, decisions, testing results and other evidence are therefore not an end in themselves. They are the material through which an organisation can show that legal and technical requirements were actually implemented.

Legal bases - Article 6

Every processing operation involving ordinary personal data requires at least one legal basis in Article 6(1). Choosing the basis is not a paperwork exercise: it influences transparency, withdrawal, objection and other rights.

Consent is highly visible but frequently misused. Article 7 requires it to be freely given, specific, informed and unambiguous, expressed through an affirmative act rather than a pre-ticked box, and as easy to withdraw as to give. Conditioning performance of a contract on consent to processing that is not necessary for that contract is a strong indication that consent may not be freely given; Article 7(4) requires that factor to receive particular weight. Consent should not be treated as the automatic legal basis for all marketing, cookies or data sharing: the controller must identify the correct GDPR basis for each purpose and separately comply with sector-specific rules governing electronic communications and information stored on or accessed from a device.

One limitation is easy to forget: Article 6(1)(f) does not apply to processing carried out by public authorities in the performance of their tasks. A public body cannot rely on legitimate interests where it acts as a public authority and must identify a basis grounded in law.

Special categories of personal data - Article 9

Article 9(1) starts from a prohibition. It covers data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs or trade-union membership; genetic data; biometric data processed for uniquely identifying a person; health data; and data concerning a person's sex life or sexual orientation. The structure is the reverse of the one for ordinary data: the starting point is a prohibition rather than a search for a basis.

Article 9(2) provides ten exceptions. Common examples include explicit consent, employment and social-security law, establishment or defence of legal claims, healthcare, public health, archiving in the public interest and scientific research. Other exceptions address vital interests, activities of certain non-profit bodies, data manifestly made public by the individual and substantial public interest grounded in law.

Article 10 separately regulates data relating to criminal convictions and offences. Such processing must be carried out under the control of official authority or be authorised by Union or Member State law providing appropriate safeguards. It is not simply another Article 9 special category.

The distinction matters in practice. A hospital can process health data under healthcare provisions, while an employer may process certain health-related information because employment law requires it. Facial recognition used to identify people processes biometric data for unique identification and therefore requires an Article 9 condition in addition to an Article 6 basis. A generic claim of "security" does not by itself create such a legal basis. Asking about health in a recruitment questionnaire is not permissible without one.

Data-subject rights - Articles 12 to 23

Chapter III establishes a set of rights and Article 12 provides common procedural rules: the controller must act without undue delay and in any event within one month, with a possible two-month extension where necessary because of complexity or the number of requests. Exercise of rights is generally free of charge, subject to the limited exceptions for manifestly unfounded or excessive requests.

Articles 13 and 14 impose transparency duties without waiting for a request. Information includes the identity of the controller, contact details of the DPO where applicable, purposes and legal bases, recipients, retention periods or criteria, relevant rights, the right to complain to a supervisory authority and information about automated decision-making where applicable. Article 13 covers data obtained from the person; Article 14 data obtained elsewhere, and the second case is more often overlooked.

Article 15 gives the right of access, including confirmation of processing, a copy of personal data and information about purposes, categories, recipients and retention. The first copy is free. Article 16 provides for rectification and completion of incomplete data.

Article 17, the right to erasure, applies in circumstances such as data no longer being necessary, valid withdrawal of consent where no other basis remains, a successful objection or unlawful processing. It is not absolute. Exceptions include legal obligations, freedom of expression and information, public-interest archiving and establishment, exercise or defence of legal claims. Article 18 allows processing to be restricted while a dispute is resolved rather than requiring deletion.

Article 20 provides data portability for data processed by automated means on the basis of consent or contract, where the statutory conditions are met. Article 21 creates a right to object to processing based on public-interest tasks or legitimate interests, subject to the controller demonstrating compelling legitimate grounds where the law permits. For direct marketing, the objection is absolute: once the individual objects, the data may no longer be processed for that marketing purpose.

Article 22 concerns decisions based solely on automated processing, including profiling, that produce legal effects or similarly significantly affect a person. It is not a general right to opt out of profiling in every context. The provision is increasingly relevant in credit scoring, automated recruitment and other consequential decision systems. Article 23 allows certain rights to be restricted by Union or Member State law for specified public interests, subject to strict safeguards.

Controller and processor obligations

Chapter IV distinguishes the two core roles. A controller determines the purposes and means of processing. A processor processes personal data on behalf of a controller and under documented instructions, subject to its own GDPR duties.

Article 24 requires controllers to implement appropriate technical and organisational measures and be able to demonstrate compliance, taking into account the nature, scope, context and purposes of processing and the risks to individuals. Article 25 develops this into data protection by design and by default: privacy must be built into systems and organisational decisions, and default settings should limit processing to what is necessary for each specific purpose. The second half is stronger than usually assumed - the default state of the service must be the most protective one, not a state the user can reach after changing settings. Earlier privacy-by-design principles^[13], ENISA engineering guidance^[10], the NIST Privacy Framework^[11] and ISO/IEC 29100 terminology^[12] can help translate those legal requirements into engineering practice.

Article 30 requires records of processing activities containing, among other things, purposes, categories of data subjects and personal data, recipients, transfers to third countries, envisaged erasure periods and a general description of security measures. The exemption for organisations with fewer than 250 employees is narrow: it does not apply, among other cases, where processing is not occasional, is likely to result in risk, or includes special-category or Article 10 data. Regular HR or customer processes often mean that a small organisation cannot rely on the exemption.

Article 32 requires security appropriate to risk and gives examples such as pseudonymisation and encryption, resilience and availability, recovery capability and - in Article 32(1)(d) - a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures. Security audits, penetration tests and vulnerability assessments can contribute evidence, but their scope and frequency should follow risk; Article 32 does not impose a universal annual penetration test or mandate one specific product.

Article 28 regulates processors and the processor contract. A processor acts on documented instructions, ensures confidentiality of authorised personnel, implements Article 32 security, assists with data-subject rights and breach obligations, deletes or returns data at the end of the service as instructed, and makes information available to demonstrate compliance. A subprocessor requires prior specific or general written authorisation in accordance with Article 28. Where two organisations jointly determine purposes and means, Article 26 makes them joint controllers and requires a transparent allocation of responsibilities, without depriving data subjects of the ability to exercise rights against each controller.

DPIA and the data protection officer

Article 35 requires a data protection impact assessment where a type of processing is likely to result in a high risk to individuals' rights and freedoms. Article 35(3) identifies three express cases: systematic and extensive evaluation of personal aspects based on automated processing, including profiling, on which legally or similarly significant decisions are based; large-scale processing of special-category or Article 10 data; and systematic monitoring of publicly accessible areas on a large scale. Supervisory authorities also publish lists of processing operations requiring a DPIA.

A DPIA describes the envisaged processing and purposes, assesses necessity and proportionality, evaluates risks to individuals and identifies measures to address them. Where high residual risk remains, Article 36 requires prior consultation with the supervisory authority before processing begins. A DPIA prepared only after deployment misses the preventive function of the instrument.

A data protection officer is mandatory in the three cases in Article 37: processing by a public authority or body, except courts acting in their judicial capacity; core activities consisting of regular and systematic monitoring of data subjects on a large scale; or core activities consisting of large-scale processing of special categories or Article 10 data. A hospital is a classic example of large-scale special-category processing; an individual medical practice is not automatically large-scale merely because it handles health data.

Article 39 assigns the DPO tasks including information and advice, monitoring compliance and internal policies, advice on DPIAs and cooperation with the supervisory authority. Article 38 protects independence: the DPO must not receive instructions about how to perform those tasks, must report to the highest management level and must not be dismissed or penalised for performing the role.

Conflict of interest is therefore critical. A person whose other role allows them to determine purposes and means of processing may not simultaneously function as an independent DPO for those same decisions. Senior management positions and some heads of IT, HR or marketing will frequently create conflicts depending on actual responsibilities. The DPO can be an employee or an external service provider. In either model, expertise, resources, direct access to management and absence of conflict must be demonstrated; outsourcing alone does not create independence.

Personal-data breaches and the 72-hour rule

A personal-data breach is a security breach leading to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data. It therefore covers confidentiality, integrity and availability. Ransomware that makes personal data unavailable can be a personal-data breach even where exfiltration has not been established.

Article 33 requires notification to the supervisory authority without undue delay and, where feasible, no later than 72 hours after the controller becomes aware of the breach, unless the breach is unlikely to result in a risk to individuals' rights and freedoms. The notification describes the nature of the breach, affected categories and approximate numbers where possible, DPO or contact details, likely consequences and measures taken or proposed. A late notification must explain the delay.

Where the breach is likely to result in a high risk, Article 34 generally requires communication to affected individuals as well. Exceptions include cases where effective technical measures, such as strong encryption with uncompromised keys, render the data unintelligible; subsequent measures remove the high risk; or individual communication would involve disproportionate effort and an equally effective public communication is used.

Article 33(5) requires documentation of all personal-data breaches, including facts, effects and remedial action, regardless of whether they are notified. This allows a supervisory authority to review not only notifications but also decisions not to notify - and those are often the decisions that become contested.

EDPB Guidelines 9/2022^[4] use examples to explain risk assessment. Loss of a strongly encrypted and properly protected device may present low risk, while loss of the same device without protection can be materially different. Misdirected email depends on data type, recipients and scale. Exposure of password hashes must be assessed in light of the actual password-hashing method, salting and surrounding controls.

The operational challenge is determining when the controller became aware of a breach. The clock does not necessarily start at the moment of the attack or the first technical alert. It starts when the controller has a reasonable degree of certainty that a security incident has led to personal data being compromised, and it runs continuously, including on non-working days. Lack of complete information does not justify waiting indefinitely: Article 33 allows information to be provided in phases. A breach at a processor does not remove the notification responsibility of the controller: the processor must notify the controller without undue delay, and the controller then applies the Article 33 and 34 tests.

Transfers outside the European Economic Area

Chapter V provides several mechanisms for transfers to third countries. In practice, the first question is whether the European Commission has adopted an adequacy decision under Article 45. Where a valid adequacy decision covers the destination and recipient, no separate Article 46 transfer mechanism is required, although all other GDPR requirements continue to apply.

The adequacy list changes. The Commission renewed the UK adequacy decision on 19 December 2025 and adopted an adequacy decision for Brazil in January 2026; the current Commission list should therefore be checked when a transfer is designed or reviewed.^[16]

Where no adequacy decision applies, Article 46 allows transfers based on appropriate safeguards. The most common mechanism is the Commission's 2021 Standard Contractual Clauses, although Binding Corporate Rules and approved codes or certification mechanisms can be relevant. Article 49 derogations are interpreted narrowly and are not a normal solution for repetitive structural transfers.

The modern transfer regime was shaped by the Court of Justice judgment in Case C-311/18, Schrems II^[3], of 16 July 2020. The Court invalidated the former EU-US Privacy Shield and confirmed that contractual clauses do not solve conflicting third-country law by themselves. Exporters and importers must assess whether the selected mechanism can work in the real legal and factual environment and, where necessary, apply supplementary measures such as encryption with keys held under the control of an entity in the Union. That documented assessment, carried out before the transfer starts, has since become a standard element of compliance.

For the United States, Commission Implementing Decision (EU) 2023/1795^[6] created the EU-US Data Privacy Framework. It provides an adequacy basis only for US organisations participating in the framework with active certification on the official list. Transfers to US recipients outside the DPF need another Chapter V mechanism, commonly SCCs, together with an assessment of the conditions affecting the transfer and any necessary supplementary safeguards.

The DPF is subject to judicial review. The General Court dismissed the action in Case T-553/23 on 3 September 2025. An appeal, Case C-703/25 P, was filed on 31 October 2025 and remains pending as of 29 August 2026. The adequacy decision therefore remains in force at that date.^[17] Organisations relying on the framework should monitor the litigation and understand which alternative transfer mechanism could be used if the legal position changes.

A practical control for US services is an inventory of vendors and destinations, verification of the active DPF status of the specific recipient where that mechanism is relied upon, and documented alternative mechanisms for recipients not covered by the framework. Certification can change or lapse, so this is not a one-time check.

Fines and supervisory practice

Article 83 provides two principal administrative-fine tiers.

EDPB Guidelines 04/2022^[5] set out a structured five-step method for calculating fines. The authority identifies the relevant infringements and statutory maximum, considers seriousness and turnover when setting a starting amount, applies aggravating and mitigating factors and checks that the final amount is effective, proportionate and dissuasive while remaining within Article 83.

Polish enforcement practice^[7] illustrates how long these cases can run. The 2019 Morele.net fine was PLN 2,830,410; the Supreme Administrative Court set the decision aside in February 2023 and the authority reconsidered the matter. The Fortum Marketing and Sales Polska case resulted in a penalty exceeding PLN 4.9 million concerning inadequate technical and organisational measures and insufficient verification of a processor, with enforcement also affecting the processor. The practical lesson is not that outsourcing transfers responsibility, but the opposite: a controller must select and supervise processors that provide sufficient guarantees.

Supervisory decisions are based on a broad range of infringements: Article 5 principles, missing or incorrect legal bases, failure to honour rights, inadequate security, missing DPIAs and defective breach handling. There is no single "most common" legal basis that can safely be generalised to every organisation.^[7]

Fines are only one enforcement tool. Article 58 also provides warnings, reprimands, orders to bring processing into compliance, orders to communicate a breach to data subjects, restrictions or bans on processing, erasure orders, certification-related measures and suspension of data flows to a third country. For some organisations, a processing ban is operationally more serious than a monetary penalty.

Relationship with other regulatory regimes

The GDPR does not replace cybersecurity law and cybersecurity law does not replace the GDPR. They protect overlapping systems from different perspectives. NIS2 and the Polish KSC focus on resilience and cybersecurity of network and information systems and regulated services; the GDPR protects the rights and freedoms of people whose personal data are processed.

If an organisation is also subject to the KSC and an event independently qualifies both as a significant cybersecurity incident and as a personal-data breach, two separate notification regimes may apply: data-protection notification under the GDPR and cybersecurity notification under the KSC. Not every KSC incident is a personal-data breach, and not every personal-data breach is a significant KSC incident. The legal tests therefore have to be applied separately.

For Polish public-sector bodies, the KRI framework can add information-security-management requirements^[15] covering all processed information, including personal data. A single organisational control may support several regimes, but evidence should still identify which legal obligation it satisfies.

The AI Act is complementary. Article 22 GDPR remains relevant to solely automated decisions regardless of how an AI system is classified. Training or operating AI on personal data still needs a GDPR legal basis and compliance with purpose limitation, transparency and the other principles. DORA regulates digital operational resilience in finance without removing data-protection obligations, and eIDAS regulates electronic identification and trust services whose providers remain subject to the GDPR when they process personal data. The threat context in which all these regimes operate is described in the annual ENISA analysis.^[14]

What to check first

A useful starting point is a map of processing activities linking each purpose to categories of data, legal basis, recipients, retention and systems. The Article 30 record can be built from that map but should not be mistaken for the whole privacy programme. Video surveillance, access-control data and HR processing should not disappear simply because they sit outside a customer-facing application.

The next layer is transparency and governance: accurate Article 13 and 14 information, documented responsibilities and evidence that the organisation actually follows its own rules. The GDPR does not require one document with a mandatory title such as "Data Protection Policy"; it requires controllers to implement and demonstrate appropriate measures.

For high-risk processing, the organisation needs a DPIA before processing begins. For Article 32 security, it needs evidence of a process for regularly testing and evaluating effectiveness. A product inventory saying "we have EDR" or "we encrypt" does not demonstrate that controls are effective in the relevant processing context.

Procedures must also work under time pressure: breach handling with a register and risk-assessment criteria, a tested 72-hour escalation path, and a data-subject request process capable of finding data across relevant systems. Third-party governance must distinguish processors from independent or joint controllers, put Article 28 contracts in place where required and document each international-transfer mechanism. The absence of any of these elements is detectable in the first hour of an inspection.