AGIDAT – Datenschutz | Informationssicherheit
GDPR Regulation (EU) 2016/679 74 key articles
EUR-Lex In force since: 2018-05-25

11 chapters · 74 articles · Plain-English summaries with AGIDAT practical notes and direct source links

74 articles

Note: This page provides English-language summaries of the GDPR for reference. For the authoritative legal text, see the official EUR-Lex publication .

Topics:
Chapter I

General Provisions

Art. 1

Subject-matter and objectives

(1) Lays down rules relating to the protection of natural persons with regard to the processing of personal data and rules relating to the free movement of such data.

(2) Protects the fundamental rights and freedoms of natural persons, in particular their right to the protection of personal data.

(3) The free movement of personal data within the Union is neither restricted nor prohibited for reasons connected with this protection.

Practical note AGIDAT · independently written

Article 1 sets out the GDPR's two co-equal aims: protecting the fundamental right to data protection and ensuring the free flow of data within the single market. That right is not absolute — it must always be weighed against other fundamental rights such as freedom of expression or freedom to conduct a business. In practice, this balancing exercise runs through the entire Regulation and should be documented wherever competing interests are weighed against each other in an audit.

Sources & references:

Art. 2

Material scope

(1) Applies to the processing of personal data wholly or partly by automated means, and to non-automated processing of personal data forming part of, or intended to form part of, a filing system.

(2) Does not apply to processing (a) outside the scope of Union law; (b) by Member States carrying out activities within the scope of Title V, Chapter 2 TEU; (c) by a natural person in the course of a purely personal or household activity; (d) by competent authorities for the prevention, investigation, detection or prosecution of criminal offences, including safeguarding against public-security threats.

(3) Processing by Union institutions, bodies, offices and agencies is governed by Regulation (EC) No 45/2001, to be aligned with the principles of this Regulation.

(4) Does not affect the application of Directive 2000/31/EC, in particular the intermediary-liability rules in its Articles 12 to 15.

Practical note AGIDAT · independently written

The material scope is broad: any structured collection of personal data — a spreadsheet, a CRM system or a paper file organised by criteria — falls under the GDPR. The household exemption only covers purely private activity with no professional link at all; a social media account used even partly for business purposes loses the exemption. This also covers manually organised card files (e.g. a doctor's patient records), and the law-enforcement exemption in general does not extend to private companies, including internal compliance investigations.

Sources & references:

Art. 3

Territorial scope

(1) Applies to processing carried out in the context of the activities of an establishment of a controller or processor in the Union, regardless of whether the processing itself takes place in the Union.

(2) Applies to processing of personal data of data subjects who are in the Union by a controller or processor not established in the Union, where the processing relates to (a) offering goods or services to such data subjects, or (b) monitoring their behaviour as far as it takes place within the Union.

(3) Applies to processing by a controller not established in the Union but in a place where Member State law applies by virtue of public international law.

Practical note AGIDAT · independently written

The market-place principle in paragraph 2 is one of the GDPR's furthest-reaching rules: a company with no EU establishment at all must still comply if it deliberately targets EU residents or monitors their behaviour, for example through tracking cookies. For EU-based companies, paragraph 1 means the GDPR applies even where the actual processing happens outside the EU, such as via a US cloud provider. In an audit, check for every SaaS vendor used whether it has an EU establishment or falls under the market-place principle, and what third-country safeguards apply (see Art. 44 et seq.).

Sources & references:

Art. 4

Definitions

Sets out the definitions used throughout the Regulation, including the following:

(1) "personal data" — any information relating to an identified or identifiable natural person ("data subject").

(2) "processing" — any operation performed on personal data, such as collection, storage, use, disclosure or erasure, whether automated or not.

(3) "restriction of processing" — marking stored personal data with the aim of limiting its future processing.

(4) "profiling" — automated processing of personal data used to evaluate or predict personal aspects of a natural person.

(5) "pseudonymisation" — processing personal data so that it can no longer be attributed to a specific data subject without additional, separately-held information.

(6) "filing system" — any structured set of personal data accessible according to specific criteria.

(7) "controller" — the person or body that alone or jointly determines the purposes and means of processing.

(8) "processor" — the person or body that processes personal data on behalf of the controller.

(9) "recipient" — a person or body to whom personal data are disclosed, with certain public authorities acting under a specific inquiry excluded.

(10) "third party" — any person or body other than the data subject, controller, processor and persons authorised to process data under their direct authority.

(11) "consent" — any freely given, specific, informed and unambiguous indication of the data subject's wishes.

(12) "personal data breach" — a breach of security leading to accidental or unlawful destruction, loss, alteration, or unauthorised disclosure of or access to personal data.

(13) "genetic data" — personal data relating to the inherited or acquired genetic characteristics of a natural person.

(14) "biometric data" — personal data from specific technical processing of physical, physiological or behavioural characteristics allowing unique identification.

(15) "data concerning health" — personal data related to the physical or mental health of a natural person, including health care services.

(16) "main establishment" — broadly, the place of a controller's or processor's central administration in the Union.

(17) "representative" — an EU-based person designated in writing under Art. 27 to represent a non-EU controller or processor.

(18) "enterprise" — a natural or legal person engaged in an economic activity.

(19) "group of undertakings" — a controlling undertaking and its controlled undertakings.

(20) "binding corporate rules" — internal data-protection policies adhered to for transfers within a corporate group.

(21) "supervisory authority" — an independent public authority established under Art. 51.

(22) "supervisory authority concerned" — a supervisory authority affected by processing owing to establishment, impact on data subjects, or a complaint lodged.

(23) "cross-border processing" — processing in the context of establishments in more than one Member State, or processing that significantly affects data subjects in more than one Member State.

(24) "relevant and reasoned objection" — an objection to a draft decision on whether there is an infringement or whether intended action complies with the Regulation.

(25) "information society service" — a service as defined in Art. 1(1)(b) of Directive (EU) 2015/1535.

(26) "international organisation" — an organisation governed by public international law and its subordinate bodies, or any other body set up by an agreement between two or more countries.

Practical note AGIDAT · independently written

Article 4 is the GDPR's terminological backbone, and imprecision here leads directly to compliance failures. Three definitions matter most in practice: 'personal data' is broad — the CJEU confirmed in Breyer that even a dynamic IP address qualifies once identification is possible; 'controller' is whoever decides purposes and means, so a cloud provider is typically a processor, not a controller; and 'consent' requires all four cumulative elements (freely given, specific, informed, unambiguous), with the EDPB confirming that pre-ticked boxes, silence or inactivity never qualify. Pseudonymised data remains personal data — only genuinely anonymised data falls outside the GDPR.

Chapter II

Principles

Art. 5

Principles relating to processing of personal data

(1) Personal data must be: (a) processed lawfully, fairly and transparently ("lawfulness, fairness and transparency"); (b) collected for specified, explicit and legitimate purposes and not further processed incompatibly with them, subject to the archiving/research/statistics carve-out in Art. 89(1) ("purpose limitation"); (c) adequate, relevant and limited to what is necessary ("data minimisation"); (d) accurate and, where necessary, kept up to date ("accuracy"); (e) kept in a form permitting identification no longer than necessary, subject to appropriate safeguards for archiving, research or statistical use ("storage limitation"); (f) processed in a manner ensuring appropriate security, including protection against unauthorised or unlawful processing and against loss, destruction or damage ("integrity and confidentiality").

(2) The controller is responsible for, and must be able to demonstrate, compliance with paragraph 1 ("accountability").

Practical note AGIDAT · independently written

The seven principles in Article 5 are the first and most important checkpoint in any data protection audit; violating any one of them can directly trigger fines under Art. 83(5) of up to €20 million or 4% of global annual turnover. Purpose limitation means customer data collected for contract performance cannot simply be reused for marketing without a fresh legal basis, and storage limitation requires a documented, actively enforced deletion concept rather than indefinite retention. The accountability principle in paragraph 2 is decisive in practice: it is not enough to comply — the controller must actively document and be able to prove compliance, and this should be reflected activity-by-activity in the records of processing (Art. 30).

Sources & references:

Art. 6

Lawfulness of processing

(1) Processing is lawful only if at least one applies: (a) the data subject has given consent; (b) necessary for performance of a contract with the data subject or pre-contractual steps at their request; (c) necessary for compliance with a legal obligation; (d) necessary to protect vital interests; (e) necessary for a task carried out in the public interest or in the exercise of official authority; (f) necessary for the legitimate interests of the controller or a third party, unless overridden by the data subject's interests or fundamental rights, in particular where the data subject is a child.

(2) Member States may maintain or introduce more specific provisions adapting the application of the rules for processing under (c) and (e).

(3) The legal basis for processing under (c) and (e) must be laid down by Union law or the law of the Member State to which the controller is subject.

(4) Where processing for a purpose other than the one for which the data were collected is not based on consent or a Union/Member State law necessary and proportionate under Art. 23(1), the controller must assess compatibility, taking into account any link between the purposes, the context of collection, the nature of the data, the possible consequences, and safeguards such as encryption or pseudonymisation.

Practical note AGIDAT · independently written

Article 6 is the GDPR's most practically important provision — without a legal basis, processing is unlawful, full stop. The six grounds in (a) to (f) rank equally; companies should not stack multiple bases 'just in case' but should identify and document the primary legal basis for each processing activity. Legitimate interest (f) requires a documented three-step balancing test — identify the interest, demonstrate necessity, and weigh it against the data subject's rights — and German supervisory authorities have repeatedly found that a bare reference to 'legitimate interests' without a concrete assessment does not hold up.

Sources & references:

Art. 7

Conditions for consent

(1) Where processing is based on consent, the controller must be able to demonstrate that the data subject has consented.

(2) If consent is given within a written declaration that also concerns other matters, the request for consent must be clearly distinguishable from those other matters, in an intelligible and easily accessible form using plain language; parts of the declaration that infringe the Regulation are not binding.

(3) The data subject has the right to withdraw consent at any time, and withdrawal must be as easy as giving it; withdrawal does not affect the lawfulness of processing carried out before withdrawal, and the data subject must be informed of this before consenting.

(4) When assessing whether consent is freely given, utmost account must be taken of whether performance of a contract — including provision of a service — is made conditional on consent to processing not necessary for that contract.

Practical note AGIDAT · independently written

Article 7 sets demanding conditions that are frequently not met in practice. The controller must always be able to prove when, how and to what a data subject consented — without proof, consent is treated as not given. The tying prohibition in paragraph 4 means consent to processing that is not necessary for a contract (e.g. a newsletter sign-up) may not be a condition for account creation, and withdrawal must be exactly as easy as giving consent — if consent was given via a checkbox, withdrawal must be too, not by letter. Separate, granular consent is required per purpose; a single blanket 'I agree to everything' does not satisfy the Regulation.

Art. 8

Conditions applicable to child's consent in relation to information society services

(1) Where Art. 6(1)(a) applies to an information society service offered directly to a child, processing is lawful where the child is at least 16 years old; below that age it is lawful only if consent is given or authorised by the holder of parental responsibility. Member States may lower this threshold by law, but not below 13 years.

(2) The controller must make reasonable efforts, taking available technology into account, to verify that parental consent was given or authorised.

(3) Does not affect the general contract law of Member States, such as rules on the validity, formation or effect of a contract involving a child.

Practical note AGIDAT · independently written

Germany kept the default age threshold at 16 (§ 8 TDDDG) rather than lowering it to 13 as some other Member States have done. Any online service, app or website that collects consent and could realistically be used by children — even if not exclusively aimed at them — should implement age-verification measures that are technically reasonable rather than absolutely foolproof, per EDPB guidance. Article 8 is not relevant for B2B services clearly aimed only at businesses, but deserves particular attention for social-media-style, gaming or educational platforms.

Art. 9

Processing of special categories of personal data

(1) Prohibits processing of data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, or trade union membership, and the processing of genetic data, biometric data for unique identification, health data, or data concerning a person's sex life or sexual orientation.

(2) The prohibition does not apply where, among other conditions: (a) the data subject has given explicit consent; (b) processing is necessary for obligations in employment, social security or social protection law; (c) necessary to protect vital interests where the data subject is incapable of consent; (d) carried out by a non-profit body with a political, philosophical, religious or trade-union aim, limited to its members; (e) the data were manifestly made public by the data subject; (f) necessary for legal claims or judicial acts; (g) necessary for substantial public-interest reasons; (h) necessary for health or social care, occupational medicine, or managing health/social-care systems; (i) necessary for public health reasons; (j) necessary for archiving, scientific/historical research or statistical purposes.

(3) Data processed under (2)(h) may only be processed by, or under the responsibility of, a professional bound by a duty of secrecy.

(4) Member States may maintain or introduce further conditions, including limitations, for genetic, biometric or health data.

Practical note AGIDAT · independently written

Article 9 imposes a stricter regime than ordinary personal data: the default is prohibition, and processing is lawful only under one of the ten listed exceptions. In practice, health data extends far beyond medical files — a sick note, a wheelchair-access marker or a first-aid log all qualify — and biometric access-control or time-tracking systems typically need either an employment-law basis or the stricter 'explicit' consent required here (a higher bar than ordinary consent under Art. 4(11)). Several German supervisory authorities have issued substantial fines for unlawful processing of health data in employment contexts, most prominently against H&M.

Sources & references:

Art. 10

Processing of personal data relating to criminal convictions and offences

Processing of personal data relating to criminal convictions and offences or related security measures based on Art. 6(1) may only take place under the control of official authority, or when authorised by Union or Member State law providing appropriate safeguards. Any comprehensive register of criminal convictions may only be kept under the control of official authority.

Practical note AGIDAT · independently written

Article 10 matters for private employers weighing whether to request criminal-record extracts during hiring. In Germany, § 30 BZRG permits requesting a certificate of good conduct only for specific roles (e.g. work with children, security-sensitive positions); without a statutory basis, an employer may not request or store such information — even where a candidate volunteers it. Compliance sanctions-screening databases are similarly covered, typically relying on § 24 BDSG as the domestic legal basis.

Sources & references:

Art. 11

Processing which does not require identification

(1) Where the purposes for which a controller processes personal data do not or no longer require identification of a data subject, the controller is not obliged to acquire, retain or process additional information solely to comply with this Regulation.

(2) Where the controller can demonstrate it is not in a position to identify the data subject, it must inform the data subject accordingly where possible; Articles 15 to 20 then do not apply, unless the data subject provides additional information enabling identification in order to exercise those rights.

(3) No further identifiers may be collected or retained for the sole purpose of complying with this Regulation.

Practical note AGIDAT · independently written

Article 11 protects companies from having to build records they neither have nor need. If a website collects only genuinely anonymised usage statistics with no realistic path back to an individual, the data subject rights under Articles 15–20 do not apply. The bar for true anonymisation is high, though — mere pseudonymisation does not qualify, since re-identification remains possible — so companies relying on Article 11 should keep clear technical documentation of how anonymisation was achieved.

Sources & references:

Chapter III

Rights of the Data Subject

Section 1: Transparency and modalities (Art. 12–12) Section 2: Information obligations (Art. 13–14) Section 3: Right of access (Art. 15–15) Section 4: Right to rectification and right to erasure (Art. 16–19) Section 5: Right to data portability (Art. 20–20) Section 6: Right to object and automated decision-making (Art. 21–22) Section 7: Restrictions (Art. 23–23)
Art. 12

Transparent information, communication and modalities for the exercise of the rights of the data subject

(1) The controller must take appropriate measures to provide all information under Art. 13 and 14 and all communications under Art. 15 to 22 and 34 in a concise, transparent, intelligible and easily accessible form, in clear and plain language — particularly for information addressed to children; provided in writing or, where appropriate, electronically, or orally on request once identity is verified.

(2) The controller must facilitate the exercise of data subject rights under Art. 15 to 22, and may only refuse to act on a request in the Art. 11(2) case where it demonstrates it cannot identify the data subject.

(3) The controller must provide information on action taken on a request under Art. 15 to 22 without undue delay and within one month, extendable by two further months where necessary given complexity or volume, with the data subject informed of any extension and its reasons within the first month; requests made electronically should be answered electronically unless otherwise requested.

(4) Where the controller does not act on a request, it must inform the data subject without delay, and at the latest within one month, of the reasons and of the possibility to lodge a complaint with a supervisory authority or seek a judicial remedy.

(5) Information and communications under Art. 13, 14 and 15 to 22 and 34 are provided free of charge; for manifestly unfounded or excessive requests, in particular due to repetitive character, the controller may charge a reasonable administrative fee or refuse to act.

(6) Where there are reasonable doubts about identity, the controller may request additional information necessary to confirm identity.

(7) Information may be combined with standardised icons to give an easily visible, intelligible and clearly legible overview of the intended processing.

Practical note AGIDAT · independently written

Article 12 is the procedural backbone for all data subject rights and sets the central deadline: requests (access, erasure, rectification, etc.) must generally be answered within one month of receipt — the clock starts on receipt of the request, not once the requester has been identified. Many companies still lack a defined process for incoming privacy requests; best practice is a named internal owner, a dedicated contact channel (e.g. privacy@company.com), and a log of every request and how it was handled. Overly burdensome identity-verification demands (e.g. requiring notarisation) can themselves be treated as an unlawful obstruction of the right.

Sources & references:

Art. 13

Information to be provided where personal data are collected from the data subject

(1) Where data are collected from the data subject, the controller must, at the time of collection, provide: (a) identity and contact details of the controller (and representative); (b) contact details of the data protection officer, if any; (c) the purposes and legal basis of processing; (d) where based on legitimate interests, those interests; (e) any recipients or categories of recipients; (f) intention to transfer data to a third country or international organisation, if applicable.

(2) In addition, to ensure fair and transparent processing, the controller must provide: (a) the storage period or criteria for determining it; (b) the existence of the right to withdraw consent; (c) the existence of rights to access, rectification, erasure, restriction, objection and portability; (d) the right to withdraw consent under Art. 6(1)(a) or 9(2)(a); (e) the right to lodge a complaint with a supervisory authority; (f) whether providing the data is a statutory or contractual requirement and the consequences of not providing it; (g) the existence of automated decision-making, including profiling, and meaningful information about the logic involved.

(3) Where data are to be further processed for a different purpose, the controller must inform the data subject of that other purpose before further processing.

(4) Paragraphs 1 to 3 do not apply where and insofar as the data subject already has the information.

Practical note AGIDAT · independently written

Article 13 governs the privacy notice given wherever a person enters their own data — contact forms, order processes, app sign-ups. All required items in paragraphs 1 and 2 must be available at the time of collection, not only on request. Common failures in practice are vague retention periods ('as long as necessary' is not sufficient — concrete periods or deletion criteria are required), missing withdrawal notices, and no mention of the right to complain to a supervisory authority. A general website privacy policy only satisfies Article 13 for website use — separate or contextual notices are needed for forms, contracts and apps.

Sources & references:

Art. 14

Information to be provided where personal data have not been obtained from the data subject

(1) Where data are not obtained from the data subject, the controller must provide the same core information as under Art. 13(1), plus the categories of personal data concerned.

(2) In addition, the controller must provide the information needed to ensure fair and transparent processing, mirroring Art. 13(2), plus the source the data originated from, and whether it came from publicly accessible sources.

(3) This information must be given within a reasonable period after obtaining the data, and at the latest within one month; if used to communicate with the data subject, at the latest at the time of first communication; if disclosure to another recipient is envisaged, at the latest when the data are first disclosed.

(4) Where the data are to be further processed for a different purpose, the controller must inform the data subject of that other purpose before further processing.

(5) The obligations do not apply where the data subject already has the information, where provision proves impossible or would involve disproportionate effort (particularly for archiving, research or statistical purposes), where obtaining or disclosure is expressly regulated by law with appropriate safeguards, or where the data are subject to an obligation of professional secrecy.

Practical note AGIDAT · independently written

Article 14 covers situations where data are not collected directly from the data subject — purchased address lists, intra-group data transfers, web-scraped or public-register data. The one-month deadline is strict, and a common failure is B2B cold outreach where purchased contact data is used without ever informing the individuals concerned, a frequently flagged violation. The 'disproportionate effort' exemption is interpreted narrowly and does not apply where the data are used to communicate directly with the person — in practice, including the Art. 14 notice in the first outreach email is a workable fix.

Sources & references:

Art. 15

Right of access by the data subject

(1) The data subject has the right to obtain confirmation whether personal data concerning them are processed and, if so, access to the data and to information on: (a) purposes; (b) categories of data; (c) recipients, in particular in third countries or international organisations; (d) envisaged storage period or criteria; (e) rights to rectification, erasure, restriction or objection; (f) the right to lodge a complaint; (g) the source of the data if not collected from the data subject; (h) the existence of automated decision-making, including profiling, and meaningful information about the logic involved.

(2) Where data are transferred to a third country or international organisation, the data subject has the right to be informed of the appropriate safeguards under Art. 46.

(3) The controller must provide a copy of the personal data undergoing processing; a reasonable fee may be charged for further copies; electronic requests should be answered in a commonly used electronic format unless requested otherwise.

(4) The right to obtain a copy must not adversely affect the rights and freedoms of others.

Practical note AGIDAT · independently written

The right of access is the most commonly exercised data subject right in practice — and frequently underestimated by companies. The EDPB has clarified that it extends broadly: data subjects are entitled not just to a list of what is held, but to copies of the underlying data itself (paragraph 3), which can include emails and internal notes that concern them. Third-party rights (paragraph 4) can limit disclosure, for example where an email also contains another person's personal data. In practice, define in advance which systems must be searched for an access request (CRM, email, ERP, phone systems, paper archives) and who is responsible — the deadline is one month (Art. 12(3)), and ignoring access requests is regularly sanctioned.

Art. 16

Right to rectification

The data subject has the right to obtain without undue delay the rectification of inaccurate personal data concerning them. Taking into account the purposes of the processing, the data subject also has the right to have incomplete personal data completed, including by means of a supplementary statement.

Practical note AGIDAT · independently written

The right to rectification is relatively straightforward: anyone who finds inaccurate data about themselves has an enforceable right to prompt correction, particularly relevant for credit-reporting agencies and medical records. In practice, if a data subject reports an incorrect address or misspelled name, it must be corrected without delay across all affected systems, including backups where technically feasible. It also covers incomplete data — a job applicant can request that a reference note be supplemented with their own comment — and corrections must be communicated to recipients under Art. 19.

Sources & references:

Art. 17

Right to erasure ('right to be forgotten')

(1) The data subject has the right to obtain erasure of personal data without undue delay where, among other grounds: (a) the data are no longer necessary for the purposes for which they were collected; (b) the data subject withdraws consent and there is no other legal basis; (c) the data subject objects under Art. 21(1) with no overriding legitimate grounds, or objects under Art. 21(2); (d) the data have been unlawfully processed; (e) erasure is required for compliance with a legal obligation; (f) the data were collected in relation to an information society service offered to a child under Art. 8(1).

(2) Where the controller has made the data public and is obliged to erase it, it must take reasonable steps, including technical measures, to inform other controllers processing the data that the data subject has requested erasure of any links to, or copies of, the data.

(3) Paragraphs 1 and 2 do not apply to the extent processing is necessary for exercising the right of freedom of expression and information; compliance with a legal obligation or performance of a public-interest task; public health reasons under Art. 9(2)(h)/(i) and 9(3); archiving, scientific/historical research or statistical purposes under Art. 89(1) where erasure would seriously impair those aims; or the establishment, exercise or defence of legal claims.

Practical note AGIDAT · independently written

The right to erasure is one of the most-discussed data subject rights — and one of the most misunderstood. There is no absolute right to instant deletion; the claim only exists where one of the six grounds in paragraph 1 applies, and statutory retention obligations (e.g. ten years for accounting records, six years for commercial correspondence under German law) commonly override a deletion request under paragraph 3(b). A documented deletion concept is essential: it should specify default retention periods, applicable statutory retention obligations, how individual erasure requests are handled, and how deletion is carried through to backups and third-party systems. The 'right to be forgotten' in paragraph 2 mainly concerns search engines and public platforms, grounded in the CJEU's landmark Google Spain ruling.

Art. 18

Right to restriction of processing

(1) The data subject has the right to obtain restriction of processing where: (a) accuracy is contested, for a period enabling verification; (b) processing is unlawful and the data subject opposes erasure and requests restriction instead; (c) the controller no longer needs the data but the data subject needs them for legal claims; (d) the data subject has objected under Art. 21(1) pending verification of overriding grounds.

(2) Where processing has been restricted, the data may — apart from storage — only be processed with the data subject's consent, for legal claims, to protect the rights of another person, or for important public-interest reasons.

(3) A data subject who obtained restriction must be informed before the restriction is lifted.

Practical note AGIDAT · independently written

Restriction of processing is a kind of 'freeze': the data remain stored but may not be actively used except in narrow exceptions. It matters most where accuracy is disputed or an objection under Art. 21 is still being assessed. In practice, CRM and HR systems need a way to flag records (e.g. a 'restricted' status) and exclude them from regular processes such as marketing or reporting, and paper files should be physically segregated; auditors should check whether systems technically support restriction and whether a documented process exists for handling such requests.

Sources & references:

Art. 19

Notification obligation regarding rectification or erasure of personal data or restriction of processing

The controller must communicate any rectification, erasure or restriction under Art. 16, 17(1) and 18 to each recipient to whom the data have been disclosed, unless this proves impossible or involves disproportionate effort. The controller must inform the data subject about those recipients if requested.

Practical note AGIDAT · independently written

Article 19 ensures that rectifications and erasures take effect not only in the originating system but also wherever the data were shared. Companies should maintain a documented record of recipients as part of their records of processing (Art. 30) — without it, this notification duty cannot realistically be fulfilled. The 'disproportionate effort' exemption applies mainly to historical, undocumented data flows; a data processing agreement clause obliging processors to relay erasure and rectification notices is good practice.

Art. 20

Right to data portability

(1) The data subject has the right to receive personal data they provided to a controller in a structured, commonly used and machine-readable format, and to transmit that data to another controller without hindrance, where (a) processing is based on consent under Art. 6(1)(a) or 9(2)(a), or on a contract under Art. 6(1)(b), and (b) processing is carried out by automated means.

(2) The data subject also has the right to have data transmitted directly from one controller to another, where technically feasible.

(3) Does not affect Art. 17, and does not apply to processing necessary for a task carried out in the public interest or exercise of official authority.

(4) Must not adversely affect the rights and freedoms of others.

Practical note AGIDAT · independently written

Data portability applies only under narrow conditions: the legal basis must be consent or contract performance (not legitimate interest), and the processing must be automated — paper files are excluded. The EDPB has clarified that 'structured, commonly used and machine-readable' means formats like JSON, XML or CSV — not a screenshot or PDF. Classic examples include fitness-tracker data, app usage data and order histories in online shops; where relevant, companies should implement a standardised export mechanism so customers can take their data to a competitor. The right does not apply to B2B or legally mandated processing (e.g. tax law).

Sources & references:

Art. 21

Right to object

(1) The data subject has the right, on grounds relating to their particular situation, to object at any time to processing based on Art. 6(1)(e) or (f), including profiling based on those provisions; the controller must stop processing unless it demonstrates compelling legitimate grounds that override the interests, rights and freedoms of the data subject, or the processing serves legal claims.

(2) Where data are processed for direct marketing, the data subject has the right to object at any time, including to related profiling.

(3) Where a data subject objects to processing for direct marketing, the data must no longer be processed for those purposes.

(4) The data subject must be explicitly informed of the right in paragraphs 1 and 2 at the latest at the time of first communication, presented clearly and separately from other information.

(5) In the context of information society services, the data subject may exercise the right to object by automated means using technical specifications, notwithstanding Directive 2002/58/EC.

(6) Where data are processed for scientific/historical research or statistical purposes under Art. 89(1), the data subject has the right to object on grounds relating to their particular situation, unless processing is necessary for a public-interest task.

Practical note AGIDAT · independently written

Article 21 contains two objection rights of different strength: for direct marketing (paragraphs 2–3) the objection is absolute — no balancing test, no exception, immediate effect — while for legitimate-interest-based processing (paragraph 1) the controller must assess whether compelling grounds override the objection. In practice, marketing lists must be scrubbed immediately and completely once a direct-marketing objection is received, and paragraph 4 requires an explicit, standalone notice of the right to object — not buried in a privacy policy but presented at the point of first contact, e.g. in its own line in a newsletter footer.

Sources & references:

Art. 22

Automated individual decision-making, including profiling

(1) The data subject has the right not to be subject to a decision based solely on automated processing, including profiling, which produces legal effects or similarly significantly affects them.

(2) Does not apply where the decision (a) is necessary for entering into or performing a contract; (b) is authorised by Union or Member State law providing suitable safeguards; or (c) is based on explicit consent.

(3) In cases (a) and (c), the controller must implement suitable measures to safeguard rights and freedoms, including at least the right to obtain human intervention, to express one's point of view, and to contest the decision.

(4) Decisions under paragraph 2 must not be based on special categories of data under Art. 9(1), unless Art. 9(2)(a) or (g) applies with suitable safeguards in place.

Practical note AGIDAT · independently written

Article 22 is gaining significant importance in the age of AI. It applies where a decision is (1) fully automated, with no human decision-maker, and (2) produces legal or similarly significant effects — such as a credit refusal, dismissal, or denial of access. AI-driven CV screening, automated creditworthiness checks or algorithm-driven contract terminations can all fall within scope. The exceptions in paragraph 2 are narrow, and safeguards under paragraph 3 — above all the right to obtain human review — must actually be implemented. Profiling alone, without a binding automated decision, does not trigger paragraph 1 but still requires disclosure under Art. 13/14.

Art. 23

Restrictions

(1) Union or Member State law may restrict, by legislative measure, the obligations and rights under Art. 12 to 22 and Art. 34, and Art. 5 insofar as it corresponds to those rights and obligations, provided such a restriction respects the essence of fundamental rights and freedoms and is a necessary and proportionate measure in a democratic society to safeguard objectives such as: national security; defence; public security; the prevention, investigation, detection or prosecution of criminal offences; other important public interests, including monetary, budgetary and taxation matters, public health and social security; the protection of judicial independence and proceedings; the prevention of breaches of ethics for regulated professions; monitoring and regulatory functions connected with official authority in the above areas; protection of the data subject or the rights of others; and the enforcement of civil law claims.

(2) Legislative measures under paragraph 1 must in particular specify the purposes of processing, categories of data concerned, the scope of the restrictions, safeguards against abuse, the identity of the controller, storage periods, risks to data subjects' rights and freedoms, and the right of data subjects to be informed of the restriction unless this would be prejudicial to its purpose.

Practical note AGIDAT · independently written

Article 23 is an opening clause for national legislators, not a direct obligation on companies. Germany has used it in the BDSG (e.g. § 29 for investigative reporting, § 32 for credit reference agencies). Where a company relies on a statutory restriction to refuse a data subject right — for instance, access during ongoing criminal proceedings — the restriction must trace back to a specific statutory provision; a blanket reference to 'business interests' does not suffice. Internal compliance investigations may fall under Art. 23(1)(d) where they aim to uncover criminal conduct, but this must be concretely justified.

Sources & references:

Chapter IV

Controller and Processor

Section 1: General obligations (Art. 24–31) Section 2: Security of personal data (Art. 32–34) Section 3: Data protection impact assessment and prior consultation (Art. 35–36) Section 4: Data protection officer (Art. 37–39) Section 5: Codes of conduct and certification (Art. 40–43)
Art. 24

Responsibility of the controller

(1) Taking into account the nature, scope, context and purposes of processing and the varying risks to natural persons, the controller must implement appropriate technical and organisational measures to ensure and be able to demonstrate that processing complies with this Regulation, reviewing and updating them as needed.

(2) Where proportionate, those measures include implementation of appropriate data protection policies by the controller.

(3) Adherence to approved codes of conduct under Art. 40 or approved certification under Art. 42 may be used to demonstrate compliance.

Practical note AGIDAT · independently written

Article 24 is the controller's core obligation: not only complying with the GDPR, but being able to prove it. A data protection management system (DPMS) is the organisational answer — documented policies, records of processing (Art. 30), regular training, processes for data subject rights, a breach log, and periodic internal audits. The risk-based approach means a small business with simple processing does not need the elaborate DPMS of a large corporation — measures must be proportionate — but in any regulatory inspection, Art. 24 is checked first: what documentation can you actually produce?

Sources & references:

Art. 25

Data protection by design and by default

(1) Taking into account the state of the art, cost of implementation, and the nature, scope, context and purposes of processing as well as the risks to natural persons, the controller must implement appropriate technical and organisational measures — such as pseudonymisation — both at the time of determining the means of processing and at the time of processing itself, designed to implement data protection principles such as data minimisation effectively.

(2) The controller must implement appropriate measures ensuring that, by default, only personal data necessary for each specific purpose are processed — regarding the amount collected, the extent of processing, the storage period and accessibility — and in particular that personal data are not made accessible without the individual's intervention to an indefinite number of people.

(3) An approved certification under Art. 42 may be used to demonstrate compliance with paragraphs 1 and 2.

Practical note AGIDAT · independently written

Privacy by design (paragraph 1) and privacy by default (paragraph 2) are among the GDPR's most influential principles for technology development. Privacy by design means data protection must be built into systems and processes from the outset rather than bolted on afterwards; privacy by default means the most privacy-friendly setting is the standard one — a cookie banner may not have a single non-essential cookie pre-activated, and social media profiles should default to private. Every new project or processing activity should carry a short privacy-by-design record describing which data protection aspects were considered at the design stage — the CJEU's Planet49 ruling grounded much of its reasoning in privacy-by-default principles.

Art. 26

Joint controllers

(1) Where two or more controllers jointly determine the purposes and means of processing, they are joint controllers and must, in a transparent arrangement, determine their respective responsibilities, in particular regarding the exercise of data subject rights and their information duties under Art. 13 and 14; the arrangement may designate a contact point for data subjects.

(2) The arrangement must duly reflect the joint controllers' respective roles and relationships vis-à-vis data subjects, and its essence must be made available to data subjects.

(3) Irrespective of the arrangement, the data subject may exercise their rights under this Regulation against and with each of the controllers.

Practical note AGIDAT · independently written

Joint controllership is more common than often assumed and frequently goes unrecognised. The CJEU has clarified repeatedly that anyone who co-determines the purposes and means of a processing activity becomes a joint controller — even unintentionally. Classic examples include a website operator embedding a Facebook 'Like' button (Fashion ID), franchise systems with a shared customer database, and group companies sharing a CRM system. The joint-controller arrangement in paragraph 1 must be in writing and its essence must be publicly accessible, commonly within the privacy policy — companies should identify every processing activity involving multiple legally independent parties and check whether an Art. 26 arrangement exists.

Art. 27

Representatives of controllers or processors not established in the Union

(1) Where Art. 3(2) applies, the controller or processor must designate in writing a representative in the Union.

(2) The obligation does not apply to occasional processing that does not include large-scale processing of special categories of data or criminal-offence data and is unlikely to result in a risk to individuals, or to public authorities and bodies.

(3) The representative must be established in one of the Member States where the data subjects whose data are processed in connection with offered goods/services or monitored behaviour are located.

(4) The representative is mandated to be addressed, in addition to or instead of the controller/processor, by supervisory authorities and data subjects on all issues related to processing.

(5) Designating a representative does not affect legal action that could be taken against the controller or processor itself.

Practical note AGIDAT · independently written

Article 27 is relevant for non-EU companies caught by the market-place principle in Art. 3(2). It does not apply directly to EU-based companies, but if you engage a non-EU service provider subject to the market-place principle, it is worth checking whether it has appointed an EU representative — this eases communication in the event of a data breach and helps you enforce your own rights as a customer. Appointing a representative does not relieve the non-EU company of its primary responsibility.

Sources & references:

Art. 28

Processor

(1) Where processing is carried out on behalf of a controller, the controller must use only processors providing sufficient guarantees to implement appropriate technical and organisational measures ensuring compliance and protection of data subject rights.

(2) A processor must not engage another processor without prior specific or general written authorisation of the controller; under general authorisation, the processor must inform the controller of any intended changes so the controller can object.

(3) Processing by a processor must be governed by a contract or other legal act setting out subject-matter, duration, nature and purpose of processing, the type of data, categories of data subjects, and the obligations and rights of the controller, requiring in particular that the processor: (a) processes only on documented instructions; (b) ensures confidentiality commitments for authorised staff; (c) takes all measures required under Art. 32; (d) respects the conditions for engaging sub-processors; (e) assists the controller in responding to data subject rights requests; (f) assists with compliance under Art. 32–36; (g) at the controller's choice deletes or returns all data after the service ends; (h) makes available all information necessary to demonstrate compliance and allows for audits.

(4) Where a processor engages another processor, the same data protection obligations must be imposed on that sub-processor by contract, and the first processor remains fully liable to the controller for the sub-processor's performance.

(5) Adherence to an approved code of conduct or certification may be used as an element to demonstrate sufficient guarantees.

(6) The contract may be based, wholly or in part, on standard contractual clauses.

(7) The Commission may lay down standard contractual clauses for the matters in paragraphs 3 and 4.

(8) A supervisory authority may also establish its own standard contractual clauses, subject to the consistency mechanism under Art. 63.

(9) The contract must be in writing, including in electronic form.

(10) A processor that processes data beyond the controller's instructions is considered a controller for that processing and subject to the liability regime of Art. 82.

Practical note AGIDAT · independently written

Article 28 is the basis for the data processing agreement (DPA) — one of the most important documents in day-to-day GDPR practice. Any cloud service, external data centre, payroll provider or IT contractor with access to personal data typically qualifies as a processor and requires a DPA in place before processing begins, not retroactively. Sub-processors (paragraphs 2 and 4) must either be individually approved or covered by a general authorisation with a right to object — a common default for cloud services. If a processor acts outside the agreed instructions, it becomes a controller in its own right (paragraph 10), with full liability consequences — auditors should maintain a complete list of processors, confirm a DPA exists for each, and confirm sub-processors are documented and approved.

Sources & references:

Art. 29

Processing under the authority of the controller or processor

A processor, and any person acting under the authority of the controller or processor with access to personal data, may only process that data on instructions from the controller, unless required to do so by Union or Member State law.

Practical note AGIDAT · independently written

Article 29 enforces the instruction principle: employees and processors may only process personal data within the scope of documented controller instructions. In practice, employees need a clear understanding of which data they may use for which purposes — underpinned by staff privacy training and an internal acceptable-use policy. Undocumented instructions carry risk: in a dispute, a processor could argue no valid instruction was received, so written or logged instructions (email, or within the DPA) are best practice.

Art. 30

Records of processing activities

(1) Every controller (and its representative, if any) must maintain a record of processing activities under its responsibility, containing: (a) name and contact details of the controller (and joint controller, representative, DPO); (b) purposes of processing; (c) description of the categories of data subjects and data; (d) categories of recipients, including in third countries or international organisations; (e) transfers to third countries, including documentation of appropriate safeguards; (f) envisaged erasure deadlines where possible; (g) a general description of technical and organisational security measures where possible.

(2) Every processor (and its representative) must maintain a record of all categories of processing carried out on behalf of a controller, covering: (a) names and contact details of processor(s), each controller, and any representative/DPO; (b) categories of processing per controller; (c) transfers to third countries, including safeguards; (d) a general description of security measures where possible.

(3) The records must be in writing, including electronic form.

(4) The controller/processor must make the record available to the supervisory authority on request.

(5) The obligations in paragraphs 1 and 2 do not apply to an organisation employing fewer than 250 persons, unless the processing is likely to result in a risk to data subjects, is not occasional, or includes special categories of data under Art. 9(1) or criminal-offence data under Art. 10.

Practical note AGIDAT · independently written

The record of processing activities (RoPA) is the GDPR's central documentation tool and typically the first thing a supervisory authority requests during an inspection. The under-250-employee exemption in paragraph 5 rarely applies in practice: it requires the processing to pose no risk, be only occasional, AND involve no special categories — all three conditions simultaneously — and since almost every company processes employee, customer or invoicing data regularly and with some risk potential, the RoPA obligation applies to virtually all organisations. Every entry should include all mandatory items from paragraph 1, particularly retention periods and a description of technical and organisational measures — a good RoPA is also the natural basis for a company's privacy notice.

Art. 31

Cooperation with the supervisory authority

The controller and processor, and their representatives if any, must cooperate, on request, with the supervisory authority in the performance of its tasks.

Practical note AGIDAT · independently written

Article 31 establishes a genuine duty to cooperate with the data protection authority. Companies must respond to inquiries, provide access to documents, and cooperate during inspections — actively obstructing or delaying such requests can itself be sanctioned. Best practice is to designate one internal owner for authority contact (typically the DPO or legal department), set an internal process for responding to regulatory inquiries, and document all correspondence with supervisory authorities.

Art. 32

Security of processing

(1) Taking into account the state of the art, cost of implementation, and the nature, scope, context and purposes of processing as well as the varying risks, the controller and processor must implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk, including as appropriate: (a) pseudonymisation and encryption; (b) the ability to ensure ongoing confidentiality, integrity, availability and resilience of systems and services; (c) the ability to restore availability and access to data in a timely manner after an incident; (d) a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures.

(2) In assessing the appropriate level of security, account must be taken of risks presented by processing, in particular from accidental or unlawful destruction, loss, alteration, or unauthorised disclosure of or access to data.

(3) Adherence to an approved code of conduct or certification may be used to demonstrate compliance with paragraph 1.

(4) The controller and processor must take steps to ensure that any person acting under their authority with access to personal data processes it only on instruction, unless required by law.

Practical note AGIDAT · independently written

Article 32 is the heart of IT security in the GDPR. The risk-based approach means required measures scale with the risk of the specific processing activity — a patient database needs stronger safeguards than a mailing list. Baseline measures that should never be missing include encryption at rest and in transit, access control with individual accounts, a least-privilege permission concept, regularly tested backups, patch management, security-relevant logging, and staff training. The 'state of the art' evolves — what was adequate in 2018 (e.g. TLS 1.1) may be inadequate today. Document your technical and organisational measures in a dedicated, versioned document with the date of the last review.

Sources & references:

Art. 33

Notification of a personal data breach to the supervisory authority

(1) In the case of a personal data breach, the controller must, without undue delay and where feasible within 72 hours of becoming aware of it, notify the competent supervisory authority under Art. 55, unless the breach is unlikely to result in a risk to individuals; a delayed notification must be accompanied by reasons.

(2) A processor must notify the controller without undue delay after becoming aware of a personal data breach.

(3) The notification must at least: (a) describe the nature of the breach, including categories and approximate numbers of data subjects and records concerned; (b) give the DPO or other contact point's details; (c) describe the likely consequences; (d) describe the measures taken or proposed to address and mitigate the breach.

(4) Where information cannot be provided at the same time, it may be provided in phases without undue further delay.

(5) The controller must document all data breaches, including facts, effects and remedial action taken, to enable the supervisory authority to verify compliance.

Practical note AGIDAT · independently written

The 72-hour notification duty is one of the most dangerous traps in GDPR practice — not because the deadline itself is short, but because many companies lack an incident-response process and detecting a breach can take too long. The clock starts once the controller becomes aware, not once all details are known — paragraph 4 allows a phased notification, so report what is known first and supplement details later. Notification is not required where the breach is unlikely to pose a risk (e.g. an encrypted laptop with an up-to-date password). Maintain an internal breach register, covering even non-notifiable incidents, and a documented incident-response process with clear responsibilities and the relevant supervisory authority's contact details.

Art. 34

Communication of a personal data breach to the data subject

(1) Where a personal data breach is likely to result in a high risk to the rights and freedoms of natural persons, the controller must communicate the breach to the data subject without undue delay.

(2) The communication must describe, in clear and plain language, the nature of the breach and contain at least the information and recommendations set out in Art. 33(3)(b), (c) and (d).

(3) Communication is not required where: (a) appropriate technical and organisational protection measures (e.g. encryption) rendered the data unintelligible to unauthorised persons; (b) the controller has since ensured the high risk is no longer likely to materialise; or (c) it would involve disproportionate effort, in which case a public communication or similar measure must be used instead.

(4) Where the controller has not already communicated the breach, the supervisory authority may require it to do so, or may decide that one of the paragraph 3 conditions is met.

Practical note AGIDAT · independently written

Article 34 sets the highest threshold: only where there is a 'high risk' (a stricter test than the mere 'risk' in Art. 33) must data subjects be informed directly — think leaked health data, financial data, or plaintext passwords, or a very large number of affected individuals. A key exemption in paragraph 3(a): if the data were fully encrypted and the key itself was not compromised, the duty to notify data subjects falls away — one of the strongest practical incentives for encryption. Communication must use 'clear and plain language,' not legal jargon, and should include concrete recommendations such as changing a password; companies should have an approved communication plan ready to cover different breach scenarios.

Art. 35

Data protection impact assessment

(1) Where a type of processing, in particular using new technologies, is likely to result in a high risk to natural persons given its nature, scope, context and purposes, the controller must, prior to processing, carry out an assessment of the impact of the envisaged processing operations on the protection of personal data.

(2) The DPO, if designated, may be consulted when carrying out a data protection impact assessment.

(3) A DPIA is required in particular for: (a) systematic and extensive evaluation of personal aspects based on automated processing, including profiling, on which decisions with legal or similarly significant effects are based; (b) large-scale processing of special categories of data or criminal-offence data; (c) systematic, large-scale monitoring of publicly accessible areas.

(4) The supervisory authority must establish and publish a list of processing operations subject to a DPIA requirement and communicate it to the EDPB.

(5) The supervisory authority may also establish and publish a list of processing operations for which no DPIA is required, communicated likewise.

(6) Before finalising the lists in paragraphs 4 and 5, the supervisory authority must apply the consistency mechanism under Art. 63 where the lists concern processing related to offering goods/services across multiple Member States, or significantly affecting data subjects there.

(7) The assessment must at least contain: (a) a systematic description of the envisaged processing operations and purposes; (b) an assessment of necessity and proportionality; (c) an assessment of risks to data subjects' rights and freedoms; (d) the measures envisaged to address the risks, including safeguards and mechanisms to ensure compliance.

(8) Compliance with approved codes of conduct under Art. 40 must be duly taken into account in assessing the impact of processing operations.

(9) The controller must seek the DPO's advice, where one has been designated, when carrying out a DPIA.

(10) A DPIA is also required where processing is carried out under Art. 6(1)(c) or (e), unless the Regulation already contains specific rules for such processing.

(11) The controller must carry out a review to assess whether processing is performed in accordance with the DPIA, at least where the risk changes.

Practical note AGIDAT · independently written

A data protection impact assessment (DPIA) is mandatory for high-risk processing and must be carried out before processing begins. German data protection authorities have published a 'must' list of processing types requiring a DPIA — including public-area video surveillance with behavioural analysis, biometric identification, telemedicine systems, and credit scoring. The DPIA has four steps: describe the processing, assess necessity and proportionality, analyse risk (threats, likelihood, severity), and define mitigation measures — if a high residual risk remains, prior consultation with the supervisory authority under Art. 36 is required. Maintain a documented threshold analysis to decide whether a DPIA is needed and run every new project through it.

Sources & references:

Art. 36

Prior consultation

(1) The controller must consult the supervisory authority prior to processing where a DPIA under Art. 35 indicates that the processing would result in a high risk in the absence of risk-mitigation measures.

(2) Where the supervisory authority considers the intended processing would not comply with this Regulation — in particular because the risk has been insufficiently identified or mitigated — it must, within up to eight weeks of the consultation request, provide written advice and may exercise its powers under Art. 58.

(3) When consulting, the controller must provide the supervisory authority with: (a) respective responsibilities of controllers/processors, especially within a group; (b) the purposes and means of the intended processing; (c) measures and safeguards for data subjects' rights and freedoms; (d) DPO contact details, if any; (e) the DPIA; (f) any other information requested.

(4) Member States must consult the supervisory authority when preparing legislative or regulatory proposals relating to processing.

Practical note AGIDAT · independently written

Prior consultation is the last safety net: where a DPIA reveals a high residual risk that cannot be adequately mitigated, the supervisory authority must be consulted before processing begins, and it has up to eight weeks to respond. In practice, prior consultations are rare in Germany — which often signals either that no DPIA was carried out, or that a high-risk outcome went unrecognised. If a company is planning complex AI systems, large-scale profiling or mass processing of sensitive data, it should consistently check whether Art. 36 is triggered.

Art. 37

Designation of the data protection officer

(1) The controller and processor must designate a data protection officer (DPO) in any case where: (a) processing is carried out by a public authority or body, except courts acting in their judicial capacity; (b) the core activities require regular and systematic monitoring of data subjects on a large scale; or (c) the core activities consist of large-scale processing of special categories of data or criminal-offence data.

(2) A group of undertakings may appoint a single DPO, provided it is easily accessible from each establishment.

(3) Public authorities/bodies may designate a single DPO for several such entities, taking account of their organisational structure and size.

(4) In other cases, a controller, processor, or associations representing controllers or processors may designate a DPO on a voluntary basis.

(5) The DPO must be designated on the basis of professional qualities, expert knowledge of data protection law and practice, and ability to fulfil the tasks under Art. 39.

(6) The DPO may be a staff member or perform the tasks on the basis of a service contract.

(7) The controller/processor must publish the DPO's contact details and communicate them to the supervisory authority.

Practical note AGIDAT · independently written

German law expands the DPO threshold significantly: § 38 BDSG requires designation once at least 20 people are regularly engaged in automated processing of personal data — in addition to the GDPR's own trigger (core activity = large-scale monitoring or special-category processing). In practice, this means almost all SMEs beyond a certain size must appoint one, internally or externally. Key requirements are expertise, independence (the DPO must not suffer disadvantages for their work), and accessibility (name and contact details published and reported to the supervisory authority) — auditors should confirm the DPO is properly appointed, reported to the relevant authority, and named in the privacy policy.

Art. 38

Position of the data protection officer

(1) The controller and processor must ensure the DPO is involved properly and in a timely manner in all data protection matters.

(2) They must support the DPO by providing the resources necessary to carry out the tasks under Art. 39, access to data and processing operations, and resources to maintain expert knowledge.

(3) They must ensure the DPO does not receive instructions on the exercise of their tasks, is not dismissed or penalised for performing them, and reports directly to the highest management level.

(4) Data subjects may contact the DPO on all matters related to processing of their data and the exercise of their rights.

(5) The DPO is bound by secrecy or confidentiality regarding the identity of data subjects, unless released from this obligation.

(6) The DPO may fulfil other tasks and duties, provided the controller/processor ensures they do not result in a conflict of interest.

Practical note AGIDAT · independently written

The DPO's institutional independence (paragraph 3) is often a point of contention in practice. A DPO who is simultaneously IT director, compliance officer or managing director has a potential conflict of interest — for example when asked to review systems they themselves introduced — and the same applies to an external DPO who is also the company's IT service provider. The CJEU has confirmed (Leistritz) that a DPO may not be dismissed for performing their role, even without special statutory protection against termination. In practice, ensure the DPO reports directly to management, receives adequate resources (time, training budget, tools) and is involved early in every privacy-relevant project.

Art. 39

Tasks of the data protection officer

(1) The DPO must at least: (a) inform and advise the controller/processor and its employees of their obligations under this Regulation and other data protection law; (b) monitor compliance, including staff awareness, training, and audits; (c) provide advice on request regarding DPIAs and monitor their performance; (d) cooperate with the supervisory authority; (e) act as the contact point for the supervisory authority, including on prior consultation, and advise on other matters as appropriate.

(2) The DPO must have due regard to the risk associated with processing operations, taking into account their nature, scope, context and purposes.

Practical note AGIDAT · independently written

The tasks in Art. 39 are minimum tasks — in practice many DPOs also coordinate breach reporting and maintain the RoPA. Importantly, the DPO advises and monitors; they do not personally bear responsibility for GDPR compliance, which remains with the controller under Art. 24. A good annual DPO report to management is a valuable audit document, covering findings, recommended measures and the status of open items.

Sources & references:

Art. 40

Codes of conduct

(1) Member States, supervisory authorities, the EDPB and the Commission must encourage the drawing up of codes of conduct intended to contribute to the proper application of the GDPR, taking account of the specific features of different sectors and the needs of micro, small and medium-sized enterprises.

(2) Associations and other bodies representing categories of controllers or processors may prepare, amend or extend codes of conduct addressing matters such as fair and transparent processing, legitimate interests, data collection, pseudonymisation, information to the public, exercise of data subject rights, information and protection of children, technical and organisational measures under Art. 24/25/32, breach notification, and out-of-court dispute resolution.

Practical note AGIDAT · independently written

Codes of conduct are industry-standard guidelines drawn up by trade associations and approved by a supervisory authority, giving companies a clear compliance framework and, where followed, evidence of good faith before regulators. Germany has approved codes for market and opinion research and for the health insurance sector, among others. It is worth checking whether an approved code of conduct exists for your industry — adherence is a strong argument in regulatory proceedings.

Sources & references:

Art. 41

Monitoring of approved codes of conduct

(1) Without prejudice to the tasks and powers of the competent supervisory authority under Art. 57 and 58, monitoring of compliance with a code of conduct may be carried out by a body with appropriate expertise, accredited for that purpose by the competent supervisory authority.

(2) A monitoring body may be accredited where it has demonstrated its independence and expertise, established procedures to assess suitability, monitor compliance and periodically review the code, established procedures to handle complaints in a transparent manner, and demonstrates its tasks do not create a conflict of interest.

Practical note AGIDAT · independently written

Article 41 establishes the institutional oversight structure for codes of conduct. For companies using a code of conduct, this means membership brings periodic external monitoring by the accredited body — increasing the compliance burden somewhat, but also offering a demonstrable advantage before supervisory authorities.

Art. 42

Certification

(1) Member States, supervisory authorities, the EDPB and the Commission must encourage the establishment of data protection certification mechanisms, seals and marks demonstrating compliance with this Regulation.

(2) In addition to adherence by controllers/processors subject to the GDPR, approved certification mechanisms may also demonstrate appropriate safeguards provided by controllers/processors outside the GDPR in the context of transfers under Art. 46(2)(f), through binding and enforceable commitments.

(3) Certification is voluntary and available via a transparent process.

Practical note AGIDAT · independently written

Privacy certifications under the GDPR are voluntary and have not yet gained wide adoption in practice, as few GDPR-specific certification schemes have been approved by regulators. One available option is ISO/IEC 27701 as an extension of ISO 27001 for privacy information management systems. Certification can serve as evidence of compliance before supervisory authorities (Art. 24(3), 25(3), 28(5)), and for processors in particular it can be a competitive advantage.

Sources & references:

Art. 43

Certification bodies

(1) Without prejudice to the tasks and powers of the competent supervisory authority under Art. 57 and 58, certification bodies with an appropriate level of data protection expertise must, after informing the supervisory authority, issue and renew certification.

(2) Certification bodies must be accredited by the competent supervisory authority and/or the national accreditation body in accordance with Regulation (EC) No 765/2008 and EN-ISO/IEC 17065/2012, plus any additional requirements set by the supervisory authority.

Practical note AGIDAT · independently written

Certification bodies for GDPR purposes must be accredited by the data protection authority specifically — general accreditation alone is not sufficient. When selecting a certification body, always verify that it is recognised by the competent supervisory authority.

Chapter V

Transfers of Personal Data to Third Countries or International Organisations

Art. 44

General principle for transfers

Any transfer of personal data which are undergoing processing, or are intended for processing after transfer, to a third country or international organisation is only permitted if the controller and processor comply with the conditions of this Chapter, and only where the other provisions of this Regulation are also respected, so that the level of protection guaranteed by this Regulation is not undermined.

Practical note AGIDAT · independently written

Article 44 is the entry barrier for all third-country transfers: transferring personal data outside the EU/EEA is only lawful where one of the mechanisms in Art. 45–49 applies. 'Transfer' also covers mere remote access from a third country — a US cloud provider whose support staff access EU customer data from the US already constitutes a transfer. Identify in your records of processing (Art. 30) every recipient in a third country and confirm which transfer mechanism applies.

Art. 45

Transfers on the basis of an adequacy decision

(1) A transfer may take place where the Commission has decided that the third country, a territory or sector within it, or the international organisation ensures an adequate level of protection.

(2) In assessing adequacy, the Commission must consider in particular the rule of law, respect for human rights, relevant general and sectoral legislation including on public security, defence, national security and criminal law and access of public authorities to data, the existence of independent supervisory authorities, and the international commitments entered into by the third country or organisation.

(3) The Commission may, by implementing act, decide that a third country, territory, sector or international organisation ensures an adequate level of protection.

(4) The implementing act must provide for a periodic review mechanism.

(5) The Commission must continuously monitor developments that could affect adequacy decisions, and may repeal, amend or suspend them where the adequate level of protection is no longer ensured.

Practical note AGIDAT · independently written

Adequacy decisions are the most convenient basis for third-country transfers: the Commission has already assessed the recipient country's level of protection, so no further safeguards are required. Adequacy decisions currently cover countries including the UK, Switzerland, Japan, South Korea, Canada (commercial organisations), New Zealand, Israel, and the United States under the EU-US Data Privacy Framework (DPF), the successor to the Privacy Shield struck down by the CJEU in Schrems II. US companies must be DPF-certified — check every US vendor's certification status at dataprivacyframework.gov.

Art. 46

Transfers subject to appropriate safeguards

(1) In the absence of an adequacy decision, a controller or processor may only transfer personal data to a third country or international organisation if it has provided appropriate safeguards, and on condition that enforceable data subject rights and effective legal remedies are available.

(2) The appropriate safeguards under paragraph 1 may, without requiring specific authorisation, consist of: (a) a legally binding and enforceable instrument between public authorities; (b) binding corporate rules under Art. 47; (c) standard data protection clauses adopted by the Commission; (d) standard data protection clauses adopted by a supervisory authority and approved by the Commission; (e) an approved code of conduct together with binding and enforceable commitments; or (f) an approved certification mechanism together with binding and enforceable commitments.

Practical note AGIDAT · independently written

Where no adequacy decision exists, Standard Contractual Clauses (SCCs) are the most widely used instrument in practice. The Commission published updated SCCs in June 2021, covering four modules (controller-to-controller, controller-to-processor, processor-to-processor, processor-to-controller). Post-Schrems II, SCCs alone may not suffice where the recipient is subject to law permitting disproportionate government access (e.g. the US CLOUD Act) — additional technical measures (such as encryption where only the EU controller holds the key) or supplementary contractual measures may be required, per the EDPB's detailed assessment framework.

Sources & references:

Art. 47

Binding corporate rules

(1) The competent supervisory authority approves binding corporate rules in accordance with the consistency mechanism under Art. 63, provided they: (a) are legally binding, apply to and are enforced by every member of the group of undertakings, including their employees; and (b) expressly confer enforceable rights on data subjects regarding the processing of their personal data.

Practical note AGIDAT · independently written

Binding corporate rules (BCRs) are designed for corporate groups with entities in third countries. They require approval by a lead supervisory authority via the consistency mechanism, making them suitable primarily for large multinationals; for SMEs, BCRs are usually impractical given the effort and long approval timelines, and SCCs under Art. 46(2)(c) are the more accessible route.

Art. 48

Transfers or disclosures not authorised by Union law

Any judgment of a court or decision of an administrative authority of a third country requiring a controller or processor to transfer or disclose personal data may only be recognised or enforced if based on an international agreement, such as a mutual legal assistance treaty, in force between the requesting third country and the Union or a Member State.

Practical note AGIDAT · independently written

Article 48 is a direct response to US disclosure orders (e.g. under the CLOUD Act or National Security Letters). A US court cannot directly compel an EU company or EU processor to hand over data absent an applicable mutual legal assistance treaty between the US and the EU. In practice, if a US cloud provider receives a US government demand for data, it must proceed through official mutual legal assistance channels (MLAT); direct disclosure on a US authority's order alone would be a GDPR violation, and this should be addressed explicitly when negotiating a DPA with US vendors.

Art. 49

Derogations for specific situations

(1) In the absence of an adequacy decision or appropriate safeguards under Art. 46 (including binding corporate rules), a transfer or set of transfers may only take place under one of the following conditions: (a) the data subject has explicitly consented after being informed of the possible risks due to the absence of an adequacy decision and appropriate safeguards; (b) necessary for performance of a contract with the data subject or pre-contractual measures at their request; (c) necessary for a contract concluded in the interest of the data subject; (d) necessary for important reasons of public interest; (e) necessary for legal claims; (f) necessary to protect vital interests where the data subject is incapable of consent; (g) made from a register intended to provide information to the public and open to consultation by the public or persons with a legitimate interest, only to the extent the conditions for consultation are met in that particular case.

(2) A transfer under paragraph 1(g) may not involve the entirety of the personal data or entire categories of data contained in the register.

Practical note AGIDAT · independently written

Article 49 is an exception clause intended to be interpreted narrowly by the CJEU and EDPB — a last resort, not a default option. Consent under (a) is problematic in practice because the required risk disclosure is extensive and consent must be freely given, making it impractical as an ongoing solution for B2B transfers absent an adequacy decision or SCCs. Contract performance under (b) only covers transfers genuinely necessary for that specific transaction — e.g. booking a direct flight to a non-EEA country necessarily involves transferring passenger data. Transfers relying on Art. 49 should be specifically documented in the records of processing.

Chapter VI

Independent Supervisory Authorities

Section 1: Independent status (Art. 51–54) Section 2: Competence, tasks and powers (Art. 55–59)
Art. 51

Supervisory authority

(1) Each Member State must provide for one or more independent public authorities responsible for monitoring the application of this Regulation, to protect the fundamental rights and freedoms of natural persons and to facilitate the free flow of data within the Union.

(2) Each supervisory authority must contribute to the consistent application of this Regulation throughout the Union.

(3) Where a Member State has more than one supervisory authority, it must designate the authority representing them in the EDPB and set out a mechanism for the others to ensure compliance with the consistency rules under Art. 60.

Practical note AGIDAT · independently written

Germany has 18 data protection authorities: the Federal Commissioner for Data Protection and Freedom of Information (BfDI) for federal bodies and certain telecoms providers, plus 16 state-level commissioners. Which authority is competent for a company depends on where it is established. The German Datenschutzkonferenz (DSK) coordinates consistent application and publishes joint guidance; for SMEs, the relevant state authority is the contact point for breach notifications (Art. 33), inquiries and complaints.

Sources & references:

Art. 52

Independence

(1) Each supervisory authority must act with complete independence in performing its tasks and exercising its powers.

(2) Members of each supervisory authority must remain free from external influence, whether direct or indirect, and must neither seek nor take instructions from anybody.

(3) Members must refrain from any incompatible action and, during their term, must not engage in any incompatible occupation, whether gainful or not.

Practical note AGIDAT · independently written

The independence of data protection authorities is a constitutionally guaranteed principle confirmed by the CJEU. Political interference with a supervisory authority is impermissible — for companies, this means enforcement decisions are shielded from political pressure, which provides certainty, but also that political lobbying to avoid a fine is not a legitimate avenue.

Art. 55

Competence

(1) Each supervisory authority is competent to perform the tasks and exercise the powers conferred on it under this Regulation within the territory of its own Member State.

(2) Where processing is carried out by public authorities in the exercise of the rights conferred on data subjects, the supervisory authority of the Member State concerned is competent.

(3) Supervisory authorities are not competent to supervise processing by courts acting in their judicial capacity.

Practical note AGIDAT · independently written

For cross-border processing, the one-stop-shop principle (Art. 56) applies: the supervisory authority at the location of the company's main establishment takes the lead. Purely domestic companies fall under their local state authority, while companies with EU-wide processing (e.g. a SaaS provider) should determine their main establishment — the place where decisions on the purposes and means of processing are actually made.

Art. 57

Tasks

(1) Without prejudice to other tasks set out in this Regulation, each supervisory authority must, within its territory: (a) monitor and enforce the application of this Regulation; (b) promote public awareness of risks, rules, safeguards and rights related to processing; (c) advise national parliament, government and other institutions on legislative measures; (d) promote awareness among controllers and processors of their obligations; (e) provide information to data subjects on exercising their rights on request; (f) handle complaints lodged by data subjects, investigate the subject matter as appropriate, and inform the complainant of progress and outcome within a reasonable period.

Practical note AGIDAT · independently written

Supervisory authority tasks go beyond enforcement to include advice and awareness-raising. Companies can proactively seek guidance from an authority, particularly for new or complex processing activities, and complaints from data subjects (point f) are actively investigated and can trigger formal enforcement measures.

Sources & references:

Art. 58

Powers

(1) Each supervisory authority has all of the following investigative powers: (a) to order the controller/processor to provide any information required for its tasks; (b) to carry out investigations in the form of data protection audits.

(2) Each supervisory authority has all of the following corrective powers: (a) to warn a controller/processor that intended processing is likely to infringe the Regulation; (b) to issue reprimands where processing has infringed the Regulation; (c) to order compliance with data subject requests; (d) to order processing to be brought into compliance, in a specified manner and within a specified period; (e) to order communication of a breach to the data subject; (f) to impose a temporary or definitive limitation, including a ban, on processing; (g) to order rectification, erasure or restriction under Art. 16, 17 and 18; (h) to withdraw a certification or order a certification body to do so; (i) to impose an administrative fine under Art. 83.

(3) Each supervisory authority has all of the following authorisation and advisory powers: (a) to approve standard contractual clauses under Art. 28(8) and 46(2)(d), following the consistency mechanism under Art. 63; (b) to approve binding corporate rules under Art. 47; (c) to accredit certification bodies; (d) to issue certifications; (e) to approve codes of conduct under Art. 40(5).

Practical note AGIDAT · independently written

The authorities' powers range from a warning to a processing ban and a fine. A processing ban (paragraph 2(f)) is effectively one of the most severe sanctions available and can directly disrupt a company's operations — the Irish DPC's temporary ban on Meta's transatlantic data transfers is a prominent example. Proactive cooperation with regulatory inquiries (Art. 31) helps avoid escalating measures, and early, open communication is generally viewed favourably by supervisory authorities.

Sources & references:

Chapter VII

Cooperation and Consistency

Section 1: Cooperation (Art. 60–62) Section 2: Consistency (Art. 63–67) Section 3: European Data Protection Board (Art. 68–76)
Art. 60

Cooperation between the lead supervisory authority and the other supervisory authorities concerned

(1) The lead supervisory authority must cooperate with the other supervisory authorities concerned in accordance with this Article, endeavouring to reach consensus, and must exchange all relevant information with them.

(2) The lead supervisory authority may at any time request mutual assistance under Art. 61 from other supervisory authorities concerned and conduct joint operations under Art. 62, in particular to carry out investigations or monitor implementation of a measure regarding a controller or processor established in another Member State.

Practical note AGIDAT · independently written

The one-stop-shop mechanism (Art. 56, 60) means cross-border companies deal with a single lead authority at the location of their main establishment, but all affected national authorities retain a say. This can lead to complex proceedings, as the Facebook/Meta case illustrates: the Irish DPC leads as the lead authority, but authorities such as Germany's BayLDA or Austria's DSB can raise objections.

Art. 63

Consistency mechanism

In order to contribute to the consistent application of this Regulation throughout the Union, the supervisory authorities must cooperate with each other and, where relevant, with the Commission through the consistency mechanism set out in this Section.

Practical note AGIDAT · independently written

The consistency mechanism ensures uniform application of the GDPR across all 27 Member States. It matters for companies where, for example, standard contractual clauses or binding corporate rules require approval, which must go through this mechanism. In practice, follow EDPB decisions and adopted guidelines, as these clarify the binding, harmonised interpretation for all EU authorities.

Art. 68

European Data Protection Board

(1) The European Data Protection Board ("the Board") is established as a body of the Union.

(2) The Board consists of the head of one supervisory authority per Member State and the European Data Protection Supervisor, or their representatives.

(3) Where the Commission participates in Board meetings, it has no voting right.

Practical note AGIDAT · independently written

The EDPB is the central EU body for consistent data protection interpretation. Its guidelines, recommendations and opinions are formally non-binding but are treated by all national supervisory authorities as authoritative interpretive guidance. For anyone responsible for privacy compliance, the EDPB website (edpb.europa.eu) is essential reading, particularly the guidelines on cookies, consent, data breaches and third-country transfers.

Chapter VIII

Remedies, Liability and Penalties

Art. 77

Right to lodge a complaint with a supervisory authority

(1) Without prejudice to any other administrative or judicial remedy, every data subject has the right to lodge a complaint with a supervisory authority, in particular in the Member State of their habitual residence, place of work, or place of the alleged infringement, if they consider that processing of data concerning them infringes this Regulation.

(2) The supervisory authority with which the complaint has been lodged must inform the complainant of the progress and outcome of the complaint, including the possibility of a judicial remedy under Art. 78.

Practical note AGIDAT · independently written

The right to complain is one of the most important enforcement rights for data subjects. Complaints can be lodged where a person lives, works, or where the alleged infringement occurred — meaning a complaint can be filed with a local German authority even against a non-German company. Companies must take every complaint-related regulatory inquiry seriously and respond within the applicable deadline; ignoring it risks escalation and enforcement action.

Sources & references:

  • Recital 141
  • Art. 78, 79 GDPR (further remedies)
Art. 78

Right to an effective judicial remedy against a supervisory authority

(1) Without prejudice to any other administrative or non-judicial remedy, every natural or legal person has the right to an effective judicial remedy against a legally binding decision of a supervisory authority concerning them.

(2) Every data subject has the right to an effective judicial remedy where the competent supervisory authority does not handle a complaint or does not inform the data subject within three months on the progress or outcome of the complaint lodged under Art. 55 and 56.

Practical note AGIDAT · independently written

Companies (legal persons) can also sue against regulatory decisions, which matters most for fines or processing bans. In Germany, this route runs through the administrative courts; observe the applicable objection and appeal deadlines, which vary by authority and decision type.

Art. 79

Right to an effective judicial remedy against a controller or processor

(1) Without prejudice to any available administrative or non-judicial remedy, including the right to lodge a complaint under Art. 77, every data subject has the right to an effective judicial remedy where they consider that their rights under this Regulation have been infringed as a result of non-compliant processing.

(2) Proceedings against a controller or processor must be brought before the courts of the Member State where the controller or processor has an establishment. Alternatively, such proceedings may be brought before the courts of the Member State where the data subject has their habitual residence, unless the controller/processor is a public authority acting in the exercise of its public powers.

Practical note AGIDAT · independently written

Beyond the regulatory route, data subjects can also bring civil proceedings directly, either at the company's place of establishment or at the data subject's habitual residence — meaning an SME could be sued far from its own location. A robust privacy programme also protects against direct claims; data subjects can seek compensation for material and non-material damage under Art. 82 in addition to any regulatory action.

Art. 80

Representation of data subjects

(1) A data subject has the right to mandate a not-for-profit body, organisation or association, properly constituted under Member State law with statutory objectives in the public interest active in the field of protecting data subjects' rights and freedoms, to exercise the rights under Art. 77, 78 and 79 on their behalf.

(2) Member States may provide that any such body, organisation or association has the right to lodge a complaint under Art. 77, and to exercise the rights under Art. 78 and 79, independently of a data subject's mandate, in that Member State.

Practical note AGIDAT · independently written

Article 80 allows consumer protection organisations and NGOs to pursue GDPR infringements on behalf of data subjects. In Germany, the Federation of German Consumer Organisations (vzbv) has repeatedly brought proceedings over privacy violations, including against Meta. For companies, this means privacy violations can trigger representative or collective actions from NGOs — another strong argument for proactive compliance management.

Sources & references:

Art. 82

Right to compensation and liability

(1) Any person who has suffered material or non-material damage as a result of an infringement of this Regulation has the right to receive compensation from the controller or processor for the damage suffered.

(2) Any controller involved in processing is liable for damage caused by processing that infringes this Regulation. A processor is liable only where it has not complied with obligations specifically directed to processors, or where it has acted outside or contrary to lawful controller instructions.

(3) A controller or processor is exempt from liability under paragraph 2 if it proves it is not in any way responsible for the event giving rise to the damage.

(4) Where more than one controller or processor is involved in the same processing and is liable for damage, each is held liable for the entire damage in order to ensure effective compensation of the data subject.

(5) A controller/processor that has paid full compensation may subsequently claim back from other controllers/processors involved the part of the compensation corresponding to their part of responsibility for the damage.

Practical note AGIDAT · independently written

Article 82 creates a direct civil compensation claim for data protection infringements. The CJEU clarified in UI v Österreich that non-material damage does not require a serious harm threshold — worry, distress or loss of control over one's own data can suffice, though the amount of compensation should remain modest absent concrete negative consequences (per later rulings). In Germany, numerous claims for non-material damages (commonly €500–5,000) have already been brought over cookie violations, missing privacy notices, or unauthorised disclosures; exculpation under paragraph 3 is possible in principle but difficult to establish in practice.

Art. 83

General conditions for imposing administrative fines

(1) Each supervisory authority must ensure that the imposition of administrative fines for infringements of this Regulation under this Article is, in each individual case, effective, proportionate and dissuasive.

(2) Fines are imposed in addition to, or instead of, measures under Art. 58(2)(a)–(h) and (j). When deciding on a fine and its amount, due regard must be given in each case to factors including: (a) the nature, gravity and duration of the infringement, the number of data subjects affected and the level of damage; (b) intentional or negligent character; (c) mitigating action taken by the controller/processor; (d) degree of responsibility, taking account of Art. 25 and 32 measures; (e) relevant previous infringements; (f) degree of cooperation with the supervisory authority; (g) categories of data affected; (h) how the infringement became known to the authority; (i) compliance with previously ordered measures; (j) adherence to approved codes of conduct or certification; (k) any other aggravating or mitigating factor.

(3) If a controller or processor intentionally or negligently commits several infringements for the same or linked processing operations, the total fine must not exceed the amount for the gravest infringement.

(4) Infringements of controller/processor obligations under Art. 8, 11, 25–39, 42 and 43 are subject to fines of up to €10,000,000, or up to 2% of total worldwide annual turnover of the preceding financial year, whichever is higher.

(5) Infringements of the processing principles and consent conditions (Art. 5, 6, 7, 9), data subject rights (Art. 12–22), third-country transfer rules (Art. 44–49), Member State law obligations under Chapter IX, or non-compliance with a supervisory authority order, are subject to fines of up to €20,000,000, or up to 4% of total worldwide annual turnover, whichever is higher.

(6) Non-compliance with an order of the supervisory authority under Art. 58(2) is subject to fines of up to €20,000,000, or up to 4% of total worldwide annual turnover, whichever is higher.

(7) Each Member State may lay down rules on whether and to what extent administrative fines may be imposed on public authorities and bodies.

(8) The exercise of these powers must be subject to appropriate procedural safeguards, including effective judicial remedy and due process.

(9) Where a Member State's legal system does not provide for administrative fines, the article may be applied so that the fine is initiated by the competent supervisory authority and imposed by the competent national courts.

Practical note AGIDAT · independently written

Article 83 is the GDPR's fining regime — and it has produced some of the largest privacy penalties in the world. Two tiers apply: up to €10m / 2% turnover for organisational failures (missing RoPA, no DPO, no DPIA), and up to €20m / 4% turnover for serious substantive violations (principles, consent, data subject rights, third-country transfers). Landmark fines include Meta (€1.2bn, Ireland, data transfers), Amazon (€746m, Luxembourg), and in Germany, H&M (€35.3m, employee surveillance) and 1&1 (€9.55m, telephone authentication). Mitigating factors under paragraph 2 — cooperation with the authority, proactive reporting, existing technical and organisational measures — meaningfully influence the eventual fine.

Art. 84

Penalties

(1) Member States must lay down the rules on other penalties applicable to infringements of this Regulation, in particular for infringements not subject to administrative fines under Art. 83, and must take all measures necessary to ensure their implementation. Such penalties must be effective, proportionate and dissuasive.

(2) Each Member State must notify the Commission by 25 May 2018 of the relevant provisions adopted under paragraph 1, and without delay of any subsequent amendments.

Practical note AGIDAT · independently written

Beyond GDPR fines, Member States may provide for additional sanctions. In Germany, § 42 BDSG creates criminal offences: anyone who unlawfully collects or processes personal data for payment, or with intent to enrich themselves or harm another, can face up to three years' imprisonment or a fine, while § 43 BDSG provides for regulatory fines for BDSG violations.

Chapter IX

Provisions Relating to Specific Processing Situations

Art. 85

Processing and freedom of expression and information

(1) Member States must by law reconcile the right to the protection of personal data with the right to freedom of expression and information, including processing for journalistic purposes and for academic, artistic or literary expression.

(2) For processing carried out for journalistic purposes or for academic, artistic or literary expression, Member States must provide exemptions or derogations from Chapters II, III, IV, V, VI, VII and IX where necessary to reconcile the right to data protection with freedom of expression and information.

Practical note AGIDAT · independently written

Article 85 creates room for media privileges. In Germany, state press laws and the Interstate Media Treaty implement these exemptions. Media companies, journalists, academics and artists can, under certain conditions, depart from information duties, access rights and other data subject rights. For companies, ordinary GDPR rules apply to press releases and media contacts — the media privilege only protects the activity of the press, broadcasting, academia and the arts themselves.

Sources & references:

Art. 88

Processing in the context of employment

(1) Member States may, by law or collective agreements, provide for more specific rules to ensure the protection of rights and freedoms regarding processing of employees' personal data in the employment context, in particular for recruitment, performance of the employment contract, management, planning and organisation of work, equality and diversity, health and safety, protection of employer or customer property, and for exercising and enjoying employment-related rights and benefits, and for termination of the employment relationship.

(2) Such rules must include suitable and specific measures to safeguard human dignity, legitimate interests and fundamental rights, with particular regard to transparency, transfers within a group of undertakings, and monitoring systems at the workplace.

Practical note AGIDAT · independently written

Employee data protection is strongly shaped in Germany by § 26 BDSG. Employee consent is treated with caution in this context because of the inherent power imbalance, so § 26 BDSG or another statutory ground should generally be the preferred legal basis instead. Employee monitoring (GPS tracking, keyloggers, email scanning) is only lawful with a concrete suspicion of a crime or serious breach and where proportionate, and works councils generally hold a co-determination right under § 87 BetrVG before technical monitoring systems are introduced.

Art. 89

Safeguards and derogations relating to processing for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes

(1) Processing for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes must be subject to appropriate safeguards for the rights and freedoms of the data subject, including technical and organisational measures ensuring data minimisation, in particular pseudonymisation, and, wherever these purposes can be fulfilled through further processing of anonymised data, that approach must be used.

(2) Where personal data are processed for scientific/historical research or statistical purposes, Member States may provide derogations from the rights under Art. 15, 16, 18 and 21, subject to the paragraph 1 conditions, where such rights are likely to render impossible or seriously impair achievement of the specific purposes, and such derogations are necessary for fulfilling those purposes.

Practical note AGIDAT · independently written

Article 89 permits derogations for research and statistics, relevant for universities, research institutions, statistical offices and companies processing anonymised research data. Germany implements this through § 27 BDSG. Pseudonymisation alone is not a free pass — pseudonymised data remains personal data, while genuinely anonymised data falls outside the GDPR entirely.

Sources & references:

Chapter X

Delegated Acts and Implementing Acts

Art. 92

Exercise of the delegation

(1) The power to adopt delegated acts is conferred on the Commission subject to the conditions set out in this Article.

(2) The delegation of power under Art. 12(8) and Art. 43(8) is conferred on the Commission for an indeterminate period from 24 May 2016.

(3) The delegation under Art. 12(8) and Art. 43(8) may be revoked at any time by the European Parliament or the Council.

Practical note AGIDAT · independently written

Article 92 is a technical, institutional provision. What matters for companies is the output of the Commission's delegated powers — for instance, Standard Contractual Clauses (SCCs) and adequacy decisions, which rest on such delegated authority and are directly relevant in day-to-day privacy practice.

Sources & references:

Art. 93

Committee procedure

(1) The Commission is assisted by a committee, which is a committee within the meaning of Regulation (EU) No 182/2011.

(2) Where reference is made to this paragraph, Art. 5 of Regulation (EU) No 182/2011 applies.

(3) Where reference is made to this paragraph, Art. 8 of Regulation (EU) No 182/2011, in conjunction with Art. 5, applies.

Practical note AGIDAT · independently written

Article 93 governs the examination procedure for the Commission's implementing acts — a technical provision with no direct relevance for company audits.

Chapter XI

Final Provisions

Art. 94

Repeal of Directive 95/46/EC

(1) Directive 95/46/EC is repealed with effect from 25 May 2018.

(2) References to the repealed Directive are construed as references to this Regulation. References to the Working Party on the Protection of Individuals under Art. 29 of Directive 95/46/EC are construed as references to the European Data Protection Board established by this Regulation.

Practical note AGIDAT · independently written

The EU Data Protection Directive 95/46/EC was superseded when the GDPR took effect on 25 May 2018. Unlike a directive, the GDPR is a directly applicable regulation — it required no national transposition and applies uniformly across the EU, which fundamentally distinguishes it from its predecessor.

Sources & references:

Art. 95

Relationship with Directive 2002/58/EC

This Regulation does not impose additional obligations on natural or legal persons regarding processing in connection with the provision of publicly available electronic communications services in public communication networks in the Union, in relation to matters for which they are already subject to specific obligations under Directive 2002/58/EC pursuing the same objective.

Practical note AGIDAT · independently written

The ePrivacy Directive (2002/58/EC), implemented in Germany via the TDDDG (formerly TTDSG), takes precedence as lex specialis over the GDPR for telecommunications and online tracking. For cookie consent, the TDDDG applies primarily, though its consent requirements are aligned with GDPR standards. The long-planned ePrivacy Regulation intended to replace the Directive remains in negotiation.

Art. 96

Relationship with previously concluded Agreements

International agreements involving the transfer of personal data to third countries or international organisations, including appropriate safeguards for data subjects, concluded by Member States prior to 24 May 2016 and which comply with Union law as applicable prior to that date, remain in force until amended, replaced or revoked.

Practical note AGIDAT · independently written

Pre-existing agreements (such as mutual legal assistance treaties) remain valid until replaced by new arrangements. This provision is not typically of direct practical relevance for companies.

Sources & references:

  • Recital 102
Art. 97

Commission reports

(1) By 25 May 2020, and every four years thereafter, the Commission must submit a report on the evaluation and review of this Regulation to the European Parliament and the Council; the reports must be made public.

(2) In the course of the evaluations and reviews under paragraph 1, the Commission must in particular examine the application and functioning of Chapter V on transfers of personal data to third countries or international organisations.

Practical note AGIDAT · independently written

The Commission reviews the GDPR every four years. The first report (2020) found the Regulation broadly functioning well, though with room for improvement in consistent enforcement and authorities' case-handling times. Amendments to the GDPR remain possible, though no fundamental overhaul is currently planned.

Sources & references:

Art. 99

Entry into force and application

(1) This Regulation enters into force on the twentieth day following its publication in the Official Journal of the European Union.

(2) It applies from 25 May 2018.

Practical note AGIDAT · independently written

The GDPR has applied since 25 May 2018. As an EU regulation, it is directly and fully applicable in every Member State with no need for national transposition; Germany's BDSG supplements and specifies the GDPR nationally but cannot restrict it. Data collected before 25 May 2018 must also be handled in a GDPR-compliant manner once it continues to be processed.

Sources & references:

  • Official Journal L 119, 4 May 2016
  • German Federal Data Protection Act (BDSG)

Legal notice: This page provides concise, independently written English-language summaries of selected GDPR articles for reference purposes — not a verbatim translation and not legal advice. For the authoritative legal text, see EUR-Lex CELEX:32016R0679. Practical notes are independently written by AGIDAT. Last reviewed: January 2025.