The GDPR in 2026: Regulation 2016/679, principles, data subject rights, DPIA, breaches, transfers and sanctions

What the GDPR is: origins and structure

Its predecessor was Directive 95/46/EC. After two decades the European Commission identified three fundamental problems. The first was fragmentation: every member state had its own implementing act, and the differences between them could be considerable, so a firm operating in several countries faced as many regimes as markets. The second was a mismatch with a reality in which data is processed in the cloud and moved between continents; the directive predated that market. The third was sanctions, in many states low enough not to affect business decisions.

The answer lay in the choice of legal form. The GDPR is a regulation, not a directive, so it applies directly and needs no transposition. Member states retained only limited discretion on matters the instrument itself names - among them processing in employment and procedural questions.

The text runs to 99 articles in eleven chapters, preceded by 173 recitals. Chapter I contains general provisions and definitions, chapter II the principles and legal bases, chapter III the rights of data subjects and chapter IV the obligations of controllers and processors. Chapter V governs transfers outside the European Economic Area, chapters VI and VII the organisation and cooperation of supervisory authorities, chapter VIII remedies and sanctions, and chapter IX specific processing situations such as journalism, archives and scientific research. The recitals are not binding, but in practice they settle interpretive doubts and supervisory authorities cite them constantly.

The Polish act of 10 May 2018 on the protection of personal data ^[2] does not transpose the regulation, because there is nothing to transpose. It does establish the President of the Personal Data Protection Office as the supervisory authority, sets out the inspection procedure, provides criminal provisions for the most serious infringements and settles the questions left to national law. What it does not contain is worth noting: Poland did not use the option to lower the age at which a child may consent to information society services, so the default limit of 16 in article 8 applies.

Territorial and material scope

Article 3 describes territorial scope through two independent criteria, and EDPB guidelines 3/2018 ^[8] show how to apply them. The first is the establishment criterion: the regulation 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 firm storing data in a US data centre is covered in full.

The second is the targeting criterion. The regulation also covers controllers and processors with no establishment in the Union where they process the data of people in it in connection with offering them goods or services - for payment or free - or with monitoring their behaviour. The second case is wider than usually supposed: it covers behavioural analytics on a website, advertising tracking and profiling, even where the provider makes no sales in the Union. An entity outside the Union that is covered must, under article 27, designate a representative in the Union whom supervisory authorities and data subjects can approach.

Material scope covers automated processing and, where the data forms or is intended to form part of a filing system, non-automated processing. The exclusions are few and narrow: activity outside the scope of Union law, the common foreign and security policy, purely personal or household activity, and the activities of competent authorities for the purposes of preventing and prosecuting crime, governed by the separate Directive 2016/680.

At the heart of the whole construction is the definition in article 4(1), under which personal data means any information relating to an identified or identifiable natural person. It is deliberately wide and covers not only obvious identifiers such as a name or a national identification number but also IP addresses, cookie identifiers and location data, so long as they allow - even in combination with other information - a particular person to be picked out. The distinction that causes most difficulty in practice concerns anonymisation and pseudonymisation: anonymised data ceases to be personal data because the process cannot be reversed, while pseudonymised data remains personal because additional information allows it to be attributed back to a person. Pseudonymisation is therefore a safeguard, not a way out of the regulation; the techniques and their limits are described in an ENISA study ^[9].

The principles of processing (article 5)

Article 5 sets out six substantive principles and one overarching one that determines how the rest are enforced. These are not programmatic slogans - each has served as an independent basis for a supervisory decision.

Lawfulness, fairness and transparency means processing must rest on one of the bases in article 6, be fair to the individual and be intelligible to them. The practical expression of that principle is a privacy notice written in language that can be read without a lawyer. Purpose limitation requires data to be collected for specified and explicit purposes and not further processed in a manner incompatible with them; a typical infringement is using data collected to perform a contract for marketing, with no separate basis. Data minimisation requires the scope of data to be limited to what is necessary - it is that principle which settles that a recruitment form does not ask about marital status or religion.

Accuracy requires data to be correct and, where necessary, kept up to date, which bears directly on decisions taken about a person. Storage limitation requires data to be erased or anonymised once the purpose is achieved; the absence of defined retention periods is among the more frequently recorded failings. Integrity and confidentiality is the security principle, expanded in article 32.

The seventh principle, accountability in article 5(2), changes the character of all the others. A controller is not only responsible for compliance with them but must be able to demonstrate that compliance. The burden of proof therefore lies with the controller rather than the supervisory authority - and that is why records, policies and evidence of what was done are not bureaucracy in this system but the only available defence.

Legal bases (article 6)

Every processing of ordinary data requires at least one of the six bases in article 6(1). The choice is not a formality, because the scope of an individual's rights depends on it - among other things whether they may object and whether they may withdraw consent.

Consent is the most visible basis and simultaneously the weakest. Article 7 requires it to be freely given, specific, informed and unambiguous, so expressed by an action rather than a pre-ticked box; it must also be as easy to withdraw as it was to give. Consent conditioned on being able to use a service is not freely given. In practice it is used where no other basis exists: in marketing, in cookies beyond the necessary ones, and when passing data to partners.

Performance of a contract covers processing necessary to perform it or for steps taken at the individual's request before entering into one. It is the most natural basis for customer data and cannot be withdrawn - withdrawing the processing would mean withdrawing from the contract. Legal obligation applies where a rule requires the processing: employee data to the extent the labour code requires, tax data, medical records. Vital interests is an exceptional basis, covering situations where consent cannot be obtained and life or health is at stake.

The last two bases divide the world of controllers in two. Public interest and official authority is the appropriate basis for government bodies and local authorities. Legitimate interests covers processing necessary for the purposes of the controller or a third party, where those interests are not overridden by the interests and rights of the individual - it is used for direct marketing to existing customers, for pursuing claims and for justified monitoring. One limitation is easy to forget, though: article 6(1)(f) does not apply to processing carried out by public authorities in the performance of their tasks. An authority therefore cannot invoke legitimate interests where it acts as public authority, and must point to a basis in a legal provision.

Special categories of data (article 9)

Article 9(1) prohibits processing data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs and trade union membership, together with genetic data, biometric data processed for the purpose of uniquely identifying a person, data concerning health, and data concerning sex life or sexual orientation. The construction is the reverse of that for ordinary data: the starting point is a prohibition, not the need to find a basis.

Ten exceptions in paragraph 2 lift the prohibition. The most important in practice are explicit consent, carrying out obligations in the field of employment and social security law, establishing or defending legal claims, health purposes covering preventive medicine, diagnosis, treatment and management of health systems, and archiving in the public interest and scientific research. The rest cover special situations: protection of vital interests, the activities of associations with political, religious or trade union aims, data manifestly made public by the individual, substantial public interest provided for by law, and public interest in the area of public health.

Separately, article 10 governs data on criminal convictions and offences. Processing it is permitted only under the control of official authority or where authorised by law providing appropriate safeguards. It is therefore not another article 9 category but a distinct and still narrower regime.

The practical effects of that division show best in examples. A hospital processes health data under the healthcare exception, and an employer processes data from a medical certificate under labour law. A facial recognition system in a shop processes biometric data for identification and therefore needs an explicit article 9 basis, which invoking property security does not supply. A question about health in a recruitment questionnaire is inadmissible without such a basis.

The rights of data subjects (articles 12 to 23)

Chapter III grants individuals eight rights, and article 12 sets the common rules for exercising them: a response without undue delay and at the latest within one month, extendable by two months in complex cases, and as a rule free of charge.

The right to information in articles 13 and 14 is the only one a controller delivers on its own initiative, without a request. It must state its identity and the contact details of the data protection officer, the purposes and legal bases, the recipients, the storage period, the rights available, the possibility of complaining to the supervisory authority and information about automated decision-making where it is used. Article 13 concerns data collected from the individual, article 14 data obtained from another source; the latter is more often overlooked.

The right of access in article 15 covers confirmation of whether data is being processed, a copy of the data and information about purposes, categories, recipients and the storage period. The first copy is free. The right to rectification in article 16 also covers completing incomplete data, and the controller must inform the recipients of the change where possible.

The right to erasure in article 17, known as the right to be forgotten, applies among other things where the data is no longer necessary, where consent has been withdrawn and there is no other basis, where an objection has succeeded, or where the processing was unlawful. It is not unconditional: it does not cover data necessary to perform a contract, comply with a legal obligation, archive or pursue claims. The right to restriction in article 18 allows processing to be suspended while a dispute is resolved - while accuracy is verified, say - rather than deleting the data.

The right to portability in article 20 covers only data processed on the basis of consent or a contract and only by automated means; the individual receives it in a machine-readable format and may ask for it to be sent to another controller. The right to object in article 21 works in two stages: against processing based on public interest or legitimate interests it requires grounds relating to the individual's particular situation, and the controller may resist it by demonstrating compelling grounds; against direct marketing it is unconditional and results in processing stopping immediately.

The eighth right, in article 22, concerns not being subject to decisions based solely on automated processing, including profiling, where they produce legal effects or similarly significantly affect the person. It matters increasingly wherever decisions are taken by credit scoring systems, automated candidate selection or dynamic pricing. Article 23 finally allows member states to restrict these rights for strictly listed purposes such as national security, defence or criminal proceedings - always by way of a legislative measure and respecting the essence of the right.

Obligations of controllers and processors

Chapter IV describes the obligations of two roles whose distinction is the basis of the whole structure of responsibility. A controller determines the purposes and means of processing; a processor acts on its documented instructions.

Article 24 requires a controller to implement technical and organisational measures ensuring and demonstrating compliance, taking account of the nature, scope and purposes of the processing. Article 25 develops that and is the provision most often skipped in practice. It requires data protection to be taken into account at the design stage and default settings to be adopted that limit processing to the necessary minimum. The second part is stronger than usually assumed: it is the default state of a service that has to be the most protective, not a state reachable after the user changes the settings themselves. The conceptual sources of that approach ^[13] and the engineering guidance ^[10] predate the regulation; the NIST privacy framework ^[11] and the terminology of ISO/IEC 29100 ^[12] also help.

Article 30 requires records of processing activities covering purposes, categories of individuals and data, recipients including third countries, envisaged erasure periods and a general description of the security measures. The exemption for organisations employing fewer than 250 people is illusory in practice, because it does not cover processing that is not occasional - and processing employee or customer data never is. The record is also the first document a supervisory authority asks for during an inspection.

Article 32 requires measures ensuring security appropriate to the risk and names, by way of example, pseudonymisation and encryption, the ability to ensure confidentiality, integrity, availability and resilience of systems, the ability to restore availability quickly after an incident and, in paragraph 1(d), regular testing, assessing and evaluating the effectiveness of those measures. The last is an evidential duty: it is the basis for audits, penetration testing and vulnerability scanning, and its absence is what most often appears in the reasoning of decisions imposing a fine (see the GDPR audit article).

Article 28 in turn sets out the obligations of a processor and the requirement for a processing agreement. The processor acts only on documented instructions, ensures those authorised are bound by confidentiality, implements the article 32 measures, assists the controller with data subject rights and with breaches, deletes or returns the data when the service ends, and makes available the information needed to demonstrate compliance. It may not engage sub-processors without the controller's authorisation. Where two entities jointly determine purposes and means they are joint controllers under article 26 and must divide their obligations transparently - though the individual may exercise their rights against either of them regardless of that division.

Impact assessment and the data protection officer

The data protection impact assessment, in article 35, is mandatory where a type of processing is likely to result in a high risk to the rights and freedoms of individuals. The regulation names three cases where the duty always arises: a systematic and extensive evaluation of personal aspects based on automated processing including profiling, producing legal or similarly significant effects; large-scale processing of special categories or of criminal conviction data; and systematic monitoring of a publicly accessible area on a large scale. The supervisory authority also publishes a list of operations requiring an assessment - in Polish practice it covers, among others, employee monitoring, profiling at significant scale, use of new technologies such as biometrics or learning systems, combining data sets from different sources, and processing children's data.

The assessment itself has four elements: a systematic description of the envisaged processing and its purposes, an assessment of necessity and proportionality against those purposes, an assessment of the risks to individuals' rights, and a description of the measures addressing them. If a high risk remains after they are applied, article 36 requires consultation with the supervisory authority before processing begins. An assessment carried out after a system is deployed therefore does not serve its function, though that is often when it is written.

A data protection officer is mandatory in the three cases named in article 37: where the processing is carried out by a public authority or body, except courts acting in their judicial capacity; where the core activities consist of regular and systematic monitoring of individuals on a large scale; and where they consist of large-scale processing of special categories or criminal conviction data. The first case covers every local authority, office and public school.

The officer's tasks, listed in article 39, cover informing and advising, monitoring compliance with the regulation and internal policies, advising on impact assessments and cooperating with the supervisory authority, for which they are the contact point. Their independence, guaranteed by article 38, is crucial: they receive no instructions on performing their tasks, report directly to the highest management level and may not be dismissed or penalised for performing them. The commonest practical problem follows from that - conflict of interest. The role cannot be held by somebody who themselves decides on purposes and means of processing, so not the head of IT, HR or marketing. The officer may be an employee or an external party; in smaller organisations the latter is more common and usually more appropriate, precisely because of independence.

Personal data breaches and the 72-hour deadline

A personal data breach is any breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data. The definition therefore covers not only a leak but also loss of availability - which is why encryption of data by ransomware is a breach even where nobody exfiltrated anything.

Article 33 requires a breach to be notified to the supervisory authority without undue delay and at the latest within 72 hours of becoming aware of it, unless it is unlikely to result in a risk to the rights and freedoms of individuals. The notification covers the nature of the breach, the categories and approximate number of individuals and records, the officer's contact details, the likely consequences and the measures taken or proposed. Notification after the deadline is possible but requires the delay to be explained. Where the risk to individuals is high, article 34 requires them to be informed as well - unless the controller had implemented measures rendering the data unintelligible, such as effective encryption with an uncompromised key, took subsequent action eliminating the high risk, or individual notification would involve disproportionate effort, allowing a public communication instead.

Regardless of whether a breach was notified, article 33(5) requires all breaches to be documented in an internal register together with the circumstances, effects and action taken. The register is meant to let the authority review the decisions in which the controller judged notification unnecessary - and those are often the ones in dispute.

EDPB guidelines 9/2022 ^[4] structure the risk assessment through examples. Loss of a laptop with an encrypted disk and strong authentication is a low-risk situation; loss of the same device unencrypted is high risk. Sending a message to the wrong recipient is assessed by scale and by the nature of the data. A leak of password hashes depends on the algorithm: modern password-hashing functions give a wholly different risk picture from obsolete unsalted hashes.

The greatest operational difficulty remains fixing the moment of becoming aware, from which the deadline runs. It is neither the moment of the event nor the moment of the first alert, but the moment the organisation has enough information to recognise that a breach has occurred. The clock runs continuously, including on non-working days. Incomplete knowledge does not excuse delay - the regulation allows notification in phases. Separately, a breach at a processor does not release the controller: it is the controller who notifies the authority, while the processor's duty is to inform it without delay.

Transfers outside the European Economic Area

Chapter V builds a hierarchy of mechanisms in which each is used only where the previous one is unavailable. At the top stand adequacy decisions under article 45, by which the European Commission finds that a third country provides protection essentially equivalent to that in the Union. No separate transfer mechanism under Chapter V or specific authorisation is then required, but all other GDPR duties still apply and the scope of the decision must be verified. The list covers, among others, Andorra, Argentina, Canada for the commercial sector, Israel, Japan, New Zealand, the Republic of Korea, Switzerland, Uruguay and the United Kingdom - for the last, the Commission renewed the decisions on 19 December 2025, with a sunset clause on 27 December 2031. The state of that list has to be checked, because it changes.

Where no decision exists, article 46 allows a transfer to rest on appropriate safeguards. Most often those are the standard contractual clauses adopted by the Commission in their 2021 version, less often binding corporate rules approved by a supervisory authority for a group of undertakings, or approved codes of conduct and certification mechanisms. Only last does article 49 permit transfers on the basis of derogations, interpreted narrowly and intended for one-off situations: explicit consent given after being informed of the risks, necessity for performance of a contract, important reasons of public interest, legal claims, protection of vital interests, or transfer from a public register. Those derogations are not suited to running a standing process.

Today's practice was shaped by the Court of Justice judgment in case C-311/18 ^[3] of 16 July 2020, which invalidated the previous adequacy mechanism for the United States and simultaneously tightened the requirements on standard contractual clauses. The Court held that a contract alone is not enough: the controller has to assess whether the law of the destination country actually allows the clauses to be performed and, if not, introduce supplementary measures such as encryption with the key held by an entity in the Union. That assessment, carried out before transfers begin and documented, has since become a standard element of compliance.

For the United States the position was changed by Commission Implementing Decision 2023/1795 ^[6] of 10 July 2023, establishing the EU-US Data Privacy Framework. It restored free transfers, but only to organisations that joined the mechanism and appear on the official list. For providers outside the list, contractual clauses together with an assessment of the destination country's law are still needed. The durability of the arrangement is contested: the General Court dismissed an action for annulment on 3 September 2025 in case T-553/23, and an appeal was lodged with the Court of Justice. Until it is decided the decision stands, but it is sensible to keep a fallback in supplier contracts.

The practical conclusion for organisations using US services is simple: a list of the services used, a check of each against the participant list, and for the rest, contractual clauses together with a documented assessment. The list has to be reviewed periodically, because participation can be withdrawn and adequacy decisions are subject to review.

Fines and supervisory practice

Article 83 provides two tiers of administrative fine. The lower - up to EUR 10 million or 2 per cent of total annual worldwide turnover, whichever is higher - covers infringements of organisational duties: data protection by design, arrangements between joint controllers, designation of a representative, processing agreements, records of processing, cooperation with the authority, the security measures of article 32, breach handling, impact assessment and the data protection officer. The higher tier - up to EUR 20 million or 4 per cent - covers infringements touching the substance of protection: the principles, the legal bases, consent, special categories, data subject rights and transfers outside the European Economic Area.

EDPB guidelines 04/2022 ^[5] structure the calculation in five steps. The authority first classifies the infringement and establishes the applicable tier, then sets a starting amount as a percentage of the statutory maximum - up to 10 per cent for low seriousness, 10 to 20 per cent for medium and above 20 per cent for high - then takes account of aggravating circumstances such as intent, lack of cooperation or previous infringements, and mitigating ones including remedial action and cooperation, and finally checks that the result stays within the limits of article 83.

Polish practice ^[7] illustrates the full path of such a case well. The fine imposed on an online retailer in 2019 came to PLN 2,830,410; the Supreme Administrative Court set that decision aside on 9 February 2023, and the authority issued a fresh ruling after reconsidering the case. A case involving an energy retailer ended with a fine exceeding PLN 4.9 million for the absence of appropriate technical and organisational measures and for failing to verify a processor, with a fine imposed on the processor as well. The conclusion from the second is important: entrusting processing does not transfer responsibility, and the duty to check that a provider offers sufficient guarantees rests with the controller and is verifiable.

The typical grounds for fines form a repeating pattern. The commonest is the absence of regular testing and evaluation of the effectiveness of safeguards, article 32(1)(d). Next come a missing or incomplete record of processing activities, failure to notify a breach in time, no impact assessment for high-risk operations, and infringement of the article 5 principles themselves, particularly on retention and minimisation.

Fines do not exhaust the authority's powers. Article 58 also provides for warnings and reprimands, orders to bring processing into compliance, orders to communicate a breach to individuals, limitation or prohibition of processing, orders to erase data, withdrawal of certification and suspension of transfers to a third country. For many organisations a temporary ban on processing is more painful than a financial penalty.

Relationships with other legislation

The GDPR does not replace cybersecurity rules and is not replaced by them - it protects a different interest. The Polish national cybersecurity system act and the NIS2 directive protect a system's ability to function, whatever data it holds; the GDPR protects the people whose data is processed. The result is a double notification duty for an incident involving personal data: article 33 requires notification to the supervisory authority within 72 hours, while the national cybersecurity system act requires an early warning to the relevant sectoral CSIRT within 24 hours of detection, a notification within 72 hours and a final report within a month. The deadlines run in parallel towards different authorities (see the KSC article and the NIS2 article).

In public sector bodies the KRI regulation is added, whose § 19 requires an information security management system ^[15] covering all information processed, including personal data. In practice a municipality's documentation for both regimes is one body of work, differing only in the perspective of the risk assessment (see the KRI article).

With the AI Act the relationship is complementary and clearest in three places: automated decisions, where article 22 applies regardless of how the system is classified; training models on personal data, which needs its own legal basis; and information duties, which in the two instruments concern different things (see the AI Act article). Similarly DORA governs the digital resilience of the financial sector without displacing duties towards customer data (see the DORA article), and eIDAS governs trust services whose providers are subject to the GDPR on general terms (see the eIDAS article). The threat context in which all these regimes operate is described in the annual ENISA analysis ^[14].

What to check first

Experience from inspections shows that a handful of documents and procedures decide the outcome, and their absence is hard to make good after an incident. The foundation is a processing map tying purpose to categories of data, legal basis, retention period and recipients, and the record of processing activities built on it - complete, so covering video surveillance, access control and employee data as well. From that come privacy notices for every category of individual and a data protection policy approved by management and genuinely known to staff.

The second group concerns risk and security. High-risk operations need an impact assessment drawn up before processing begins, and the article 32 measures need evidence of testing, because without it point (d) is unmet however good the safeguards themselves are.

The third group is the procedures that have to work under time pressure: breach handling with a register, risk assessment criteria and a tested 72-hour notification path, and handling data subject requests with a one-month deadline and a defined escalation route. The fourth group concerns third parties: processing agreements with every provider that has access to data, and a documented state of transfers outside the European Economic Area - a list of services, a basis for each and a way of responding to a change in Commission decisions. The absence of any of those is detectable in an inspection within the first hour.