Article 12 — Transparent information, communication and modalities

Article 12 GDPR

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

1. Introduction and Purpose of Article 12 GDPR

Article 12 GDPR is the foundational procedural provision governing how controllers must communicate with data subjects and facilitate the exercise of their rights under Chapter III of the GDPR. Although the substantive rights of data subjects are contained in Articles 15 to 22 GDPR, those rights would remain largely theoretical unless individuals are able to understand how their data is processed, identify their available rights, communicate effectively with controllers, and receive meaningful responses within reasonable timeframes.

Accordingly, Article 12 does not create an independent substantive right of the data subject. Rather, it establishes the operational framework that gives practical effectiveness to the rights guaranteed under the GDPR.

The provision reflects a fundamental principle of European data protection law: information asymmetry between controllers and individuals must be reduced. Modern data processing activities are often highly complex, involving large-scale digital infrastructures, artificial intelligence systems, automated decision-making, profiling, cloud environments, advertising ecosystems, and multiple third-party processors. In such circumstances, individuals cannot realistically exercise control over their personal data unless controllers communicate information in a manner that is understandable, accessible, and actionable.

Article 12 therefore transforms transparency from a mere disclosure obligation into an active responsibility of controllers. It requires controllers not merely to make information available but to ensure that individuals can actually understand and use that information.

This approach is consistent with Article 5(1)(a) GDPR, which establishes lawfulness, fairness and transparency as one of the fundamental principles governing processing of personal data.

The importance of Article 12 can be understood through a simple analogy:

A person cannot meaningfully exercise a right that they do not know exists, cannot understand, or cannot practically invoke.

For example:

A social media platform may provide users with a 20-page privacy policy explaining extensive data processing activities. However, if the policy is written in highly technical language, hides important information regarding advertising profiling, and does not provide an easy mechanism to object to processing, the controller has technically disclosed information but has failed to satisfy Article 12.

Thus, transparency under the GDPR is not satisfied merely by disclosure; it requires effective communication.

2. Article 12 as the Gateway Provision of Chapter III GDPR

Chapter III of the GDPR contains the rights of data subjects, including:

• Article 15, Right of access

• Article 16, Right to rectification

• Article 17, Right to erasure (“right to be forgotten”)

• Article 18, Right to restriction of processing

• Article 19, Notification obligation regarding rectification, erasure or restriction

• Article 20, Right to data portability

• Article 21, Right to object

• Article 22, Rights relating to automated decision-making

Article 12 appears at the beginning of this chapter because it establishes the common procedural rules applicable to the exercise of these rights.

The rights contained in Chapter III operate in two different ways:

(a) Rights requiring a request from the data subject

Certain rights are activated only when a data subject makes a request.

Examples

• A user requests a copy of personal data under Article 15.
• An employee requests correction of inaccurate information under Article 16.
• A customer objects to direct marketing under Article 21. In these situations, Article 12 governs:
• how the request should be made easier;
• how the controller must respond;

• the timeline for response;

• whether fees can be charged;

• whether identity verification can be required.

(b) Rights and obligations requiring proactive controller action

Certain GDPR obligations require controllers to communicate without waiting for a request.

Examples

• Article 13, Information collected directly from the data subject.
• Article 14, Information obtained from another source.
• Article 34, Communication of personal data breaches to data subjects. Article 12 establishes the communication standards applicable to these situations. Therefore, Article 12 operates horizontally across multiple GDPR provisions. It applies whenever controllers:

1. provide privacy information;

2. respond to rights requests;

3. communicate breach notifications;

4. design mechanisms for exercising rights.

3. Relationship between Article 12 and the Principle of Transparency under Article 5(1)(a)

Article 12 is closely connected with Article 5(1)(a) GDPR.

Article 5(1)(a) establishes transparency as a general principle:

Personal data shall be processed lawfully, fairly and in a transparent manner in relation to the data subject.

Article 12 explains what transparency means in practice.

The relationship can be understood as:

A controller cannot claim compliance with transparency merely because information exists somewhere.

For example:

A banking application processes customer data for:

• fraud detection;

• credit scoring;

• personalised offers;

• behavioural analytics.

The bank publishes a privacy notice stating:

“We may process information for improving customer experience and operational purposes.”

Although technically a disclosure exists, the explanation fails Article 12 because it does not explain:

• what data is processed;

• whether profiling occurs;

• whether automated decisions are made;

• whether information is shared with advertisers.

Transparency requires meaningful disclosure, not formal compliance.

4. Legislative Objective Behind Article 12

Article 12 responds to several historical problems in privacy regulation:

4.1 Excessively long privacy notices

Before the GDPR, many organisations relied on lengthy privacy policies designed primarily to protect the organisation rather than inform individuals.

Common characteristics included:

• complicated legal terminology;

• extensive disclaimers;

• vague descriptions;

• buried information;

• unclear explanations of data sharing.

The GDPR sought to move away from the idea of “notice and consent” towards meaningful transparency.

A privacy notice should answer practical questions:

• What information is collected?

• Why is it collected?

• Who receives it?

• How long is it retained?

• What rights does the individual have?

• How can those rights be exercised?

4.2 Information overload

Article 12 recognises that providing too much information can be as harmful as providing insufficient information.

A privacy notice containing thousands of words may technically include all required information under Articles 13 and 14 but still fail transparency requirements because individuals cannot identify relevant information.

This creates the concept of:

Information overload

where excessive disclosure prevents meaningful understanding.

The GDPR therefore requires information to be:

• concise;

• structured;

• relevant;

• prioritised.

5. Article 12(1): Requirement of Clear and Transparent Communication

Article 12(1) provides that controllers must take appropriate measures to provide information under Articles 13 and 14 and communications under Articles 15, 22 and 34 GDPR in:

1. concise form;

2. transparent form;

3. intelligible form;

4. easily accessible form;

5. clear and plain language.

These requirements apply cumulatively.

A communication must satisfy all elements.

For example:

A privacy notice may be:

• concise but not intelligible;

• clear but not easily accessible;

• accessible but not transparent.

Any failure may undermine compliance.

6. “Appropriate Measures”, Controller's Responsibility

Article 12 requires controllers to take appropriate measures.

This gives controllers flexibility because communication methods depend on:

• nature of processing;

• complexity of technology;

• audience;

• risks involved;

• available communication channels.

A small retailer processing customer emails may satisfy Article 12 through:

• a short privacy notice;

• email confirmation;

• simple consent mechanism.

However, a multinational technology company using AI-driven profiling may require:

• layered privacy notices;

• explanatory videos;

• dashboards;

• FAQs;

• interactive tools.

The complexity of processing does not reduce transparency obligations.

In fact, complex processing requires greater transparency efforts.

The EDPB has repeatedly emphasised that organisations cannot argue:

“Our processing is too complex to explain.”

Complexity is a reason to improve communication, not avoid it.

7. Requirement One: Concise Information

The requirement of conciseness prevents controllers from overwhelming individuals with unnecessary information.

Conciseness does not mean incomplete information.

It means:

• eliminating unnecessary repetition;

• prioritising important information;

• presenting information logically.

A privacy notice should not resemble a legal contract.

Example

Poor approach “The company may, from time to time, subject to applicable laws and regulations, process certain categories of information which may include personal information relating to customers, users, visitors and other individuals for purposes including but not limited to…” This language is technically comprehensive but difficult to understand.

Better approach

“We collect your name, email address and payment details to process your orders. We use your purchase history to recommend products. You may object to personalised recommendations at any time.”

The second approach provides meaningful understanding.

8. Layered Privacy Notices

One of the most recognised methods of achieving conciseness is the use of layered privacy notices.

A layered notice presents information progressively.

First layer:

Provides essential information:

• identity of controller;

• purpose of processing;

• major rights;

• contact details.

Second layer:

Provides additional details:

• retention periods;

• recipients;

• international transfers;

• legal basis.

Third layer:

Provides detailed legal information.

The EDPB supports layered approaches because they allow individuals to quickly locate information relevant to them.

However, layering cannot be used to hide controversial processing activities.

For example:

A company cannot place information about selling personal data to advertisers on the fifth page while highlighting “better user experience” on the first page.

The most important and unexpected processing activities must be easily visible.

9. Requirement Two: Transparent Information and Communication

The second requirement under Article 12(1) GDPR is that information provided to data subjects must be transparent.

Transparency is one of the most important and frequently misunderstood concepts under the GDPR. It does not merely mean that a controller discloses information. Instead, transparency requires that the data subject receives information in a manner that allows them to understand the reality, consequences, and implications of the processing activity.

Transparency therefore contains three interconnected elements:

1. Openness, the controller must honestly disclose what processing occurs.

2. Comprehensibility, the data subject must understand the meaning of the information.

3. Predictability, the data subject must be able to reasonably anticipate how their data will be used.

A controller violates transparency where it technically provides information but presents it in a manner that prevents meaningful understanding.

9.1 Transparency as an Anti-Deception Principle

Transparency requires controllers to communicate processing activities honestly and fairly.

A controller cannot use:

• vague terminology;

• misleading descriptions;

• marketing language;

• hidden disclosures;

• ambiguous expressions;

to minimise the perceived impact of processing.

The objective is to ensure that individuals are not surprised by how their personal data is used.

Example 1

Non-transparent advertising practices A mobile application collects users' location data. The privacy notice states: “We use location information to improve your experience.” However, the actual purpose is:

• creating behavioural profiles;

• identifying shopping patterns;

• sharing insights with advertising partners.

Although the phrase “improve your experience” appears positive, it fails transparency because it does not reveal the actual purpose of processing.

A transparent explanation would state:

“We collect your precise location data to provide location-based recommendations and to create advertising profiles. We may share aggregated insights with advertising partners.”

The second explanation enables the user to make an informed decision.

9.2 Transparency and Fairness under Article 5(1)(a)

Transparency is closely connected with fairness.

A processing activity may technically satisfy a legal basis requirement but still violate transparency.

For example:

A financial institution processes customer transaction data for fraud prevention.

Fraud prevention is a legitimate purpose.

However, if the institution secretly analyses spending habits to predict:

• lifestyle choices;

• political preferences;

• personal interests;

without informing customers, the processing may violate transparency and fairness.

The issue is not merely whether the processing is lawful, but whether individuals could reasonably expect such processing.

9.3 Transparency in Artificial Intelligence Systems

Article 12 has become increasingly important with the growth of artificial intelligence.

AI systems frequently involve:

• automated decision-making;

• predictive analytics;

• profiling;

• machine learning models;

• complex data relationships.

Traditional privacy notices often fail to explain AI processing because they describe data collection but not algorithmic decision-making.

For AI systems, transparency requires explaining:

• that AI is being used;

• the purpose of AI deployment;

• categories of data used;

• consequences of AI outputs;

• whether humans review decisions;

• how individuals can challenge outcomes.

Example

AI recruitment tool A company uses an AI system to rank job applicants. A poor privacy notice states: “Applicant information may be processed for recruitment purposes.” This does not explain:

• that AI evaluates applicants;

• what factors influence ranking;

• whether automated decisions occur.

A transparent notice would state:

“We use an AI-based recruitment tool to analyse applications and identify candidates whose qualifications match job requirements. The system evaluates information such as education, experience and skills. Human recruiters review final decisions. You have the right to request human intervention and contest decisions.”

10. Requirement Three: Intelligible Information

The third requirement under Article 12(1) GDPR is that information must be intelligible.

Intelligibility focuses on whether the intended audience can actually understand the information provided.

The question is not:

“Would a privacy lawyer understand this notice?”

The question is:

“Would the ordinary person whose data is being processed understand this notice?”

10.1 Audience-Based Approach

Controllers must consider the characteristics of their audience.

Different audiences require different communication styles.

A controller processing data of:

• lawyers;

• cybersecurity professionals;

• medical researchers;

may use some technical terminology.

However, a controller providing services to:

• children;

• elderly individuals;

• ordinary consumers;

must adopt simpler language.

Example

Medical service provider A hospital privacy notice stating: “Your PHI may be processed pursuant to applicable healthcare interoperability frameworks.” may be understandable to compliance professionals but confusing to patients. A patient-friendly explanation would be: “We use your health information to provide medical care, maintain your records, process insurance claims and improve healthcare services.”

10.2 Avoiding Legal and Technical Jargon

The GDPR does not prohibit legal terminology completely. However, unnecessary complexity violates Article 12.

Common problematic expressions include:

“Data may be processed for legitimate business purposes.”

Problem:

The phrase does not explain:

• what business purposes;

• what data;

• what impact.

Better:

“We process your email address and purchase history to send product recommendations and improve customer support.”

“Information may be shared with selected third parties.”

Problem:

The identity of recipients remains unclear.

Better:

“We share your payment information with payment processors such as banks and payment gateway providers to complete transactions.”

11. Requirement Four: Easily Accessible Form

Information must be provided in a manner that is easily accessible.

This means the individual should not have to conduct extensive searches to locate privacy information.

The controller must ensure that:

• privacy information is visible;

• access is simple;

• users know where to find it.

11.1 Accessibility Does Not Mean Mere Availability

A common mistake is assuming that placing a privacy policy somewhere on a website satisfies Article 12.

It does not.

A privacy policy hidden:

• in website footers;

• behind multiple links;

• inside lengthy terms of service;

may not satisfy accessibility requirements.

Example

Mobile Application A banking application provides a privacy policy only on its website. However, users primarily interact through the mobile application. A better approach would be: Within the application: Settings → Privacy → Your Data → Privacy Rights

The user should be able to access privacy information without difficulty.

11.2 The “Two-Tap” Principle

The former Article 29 Working Party suggested that privacy information in applications should generally be available within approximately two interactions.

Although not a strict legal rule, it reflects the principle that privacy information should be immediately accessible.

Example

A weather application: Poor design: Home screen → Settings → Account → Legal → Terms → Privacy Policy Better: Home screen → Privacy

11.3 Accessibility for Persons with Disabilities

Article 12 also supports inclusive communication.

Controllers should consider:

• visually impaired users;

• hearing-impaired users;

• persons with cognitive disabilities.

Appropriate measures may include:

• screen-reader compatible notices;

• audio explanations;

• subtitles;

• simple visual explanations.

12. Requirement Five: Clear and Plain Language

Article 12 requires information to be communicated using clear and plain language.

This requirement is particularly important because privacy notices are often drafted by:

• lawyers;

• compliance teams;

• technical specialists.

However, the final audience is the individual.

The communication must therefore move from:

legal protection language

to

user understanding language.

12.1 Characteristics of Clear Language

Clear language generally requires:

Short sentences

Poor:

“The controller reserves the right, subject to applicable legal requirements and regulatory obligations, to undertake processing activities relating to personal data categories collected from multiple sources.”

Better:

“We may collect information about you from other sources, such as public databases and service providers.”

Active voice

Poor:

“Personal information may be processed by us.”

Better:

“We process your personal information.”

Specific explanations

Poor:

“We use data to improve services.”

Better:

“We analyse customer feedback and usage patterns to improve application performance.”

12.2 Avoiding Ambiguous Words

The EDPB has criticised vague expressions such as:

• may;

• might;

• sometimes;

• certain partners;

• relevant purposes;

• business needs.

Such words create uncertainty.

Example

Statement: “We may share your information with partners.” Questions remain:

• Which partners?
• Why?
• What information?

• How long?

A clearer statement:

“We share your email address with our email delivery provider to send newsletters.”

13. Information Specifically Addressed to Children

Article 12 specifically emphasises that information addressed to children requires additional care.

This reflects the GDPR's recognition that children are more vulnerable in the digital environment.

Children may:

• have limited understanding of privacy risks;

• be less able to evaluate consequences;

• be more easily influenced.

Therefore, controllers must adapt:

• vocabulary;

• tone;

• examples;

• presentation style.

13.1 Child-Friendly Communication

A privacy notice for children should avoid:

• legal terminology;

• complex sentences;

• abstract explanations.

Example

Adult privacy notice: “Your personal data will be processed for the purposes of providing personalised services.” Child-friendly version: “We use some information about you to make the app work better for you and show you things you might like.”

13.2 Children and Online Platforms

This requirement is particularly relevant for:

• gaming platforms;

• educational applications;

• social media;

• video-sharing platforms.

For example:

A gaming company collecting children's voice recordings should explain:

Not:

“Voice data may be processed for service optimisation.”

Instead:

“We use your voice recordings to make voice chat work. We do not use them to identify you or advertise products.”

14. Form of Communication under Article 12(1)

Article 12 provides flexibility regarding the method of communication.

Information may be provided:

1. in writing;

2. electronically;

3. through other appropriate methods;

4. orally upon request.

The chosen method must be suitable for the circumstances.

14.1 Written Communication

Written information remains the traditional method.

Examples

• privacy notices;
• letters;
• contractual documents. However, written information alone does not guarantee compliance. A 30-page unreadable privacy policy may still violate Article 12.

14.2 Electronic Communication

Digital environments require digital transparency mechanisms.

Examples

• privacy dashboards;
• pop-up notices;
• interactive explanations;
• mobile application notifications;
• online forms. Modern controllers increasingly use:

• just-in-time notices;

• contextual explanations;

• privacy centres.

Example

Smart device A smart speaker collects voice recordings. Instead of only providing a privacy policy during purchase, the device can provide:

• a quick explanation during setup;
• a privacy dashboard;
• voice-accessible privacy information.

15. Oral Communication under Article 12(1)

Article 12(1) GDPR provides that information may be provided orally where:

1. the data subject requests oral communication; and

2. the identity of the data subject is proven through other means.

This provision recognises that written communication is not always accessible or appropriate for every individual.

For example:

• a visually impaired individual may prefer oral communication;

• an elderly person may find written privacy notices difficult to understand;

• a person with limited literacy may require verbal explanation.

However, Article 12 does not create an automatic obligation on controllers to provide every communication orally.

The controller may provide oral information only upon request.

Example

Healthcare context A patient requests access to medical information. The hospital normally provides information through a secure online portal. However, the patient requests an oral explanation. The hospital may provide oral communication after verifying identity through appropriate means. Possible verification methods:

• patient number;

• appointment details;

• existing authentication mechanism.

The hospital should not disclose sensitive medical information merely because someone claims to be the patient.

16. Article 12(2): Obligation to Facilitate Exercise of Data Subject Rights

Article 12(2) provides:

“The controller shall facilitate the exercise of data subject rights under Articles 15 to 22.”

This is one of the most important obligations in Article 12.

The GDPR does not merely require controllers to tolerate rights requests.

It requires controllers to actively make the exercise of rights easier.

The word “facilitate” creates a positive obligation.

A controller must design systems, procedures, and communication channels that enable individuals to exercise their rights effectively.

16.1. Meaning of “Facilitate”

Facilitation requires controllers to remove unnecessary obstacles.

A controller should not:

• make requests unnecessarily complicated;

• require excessive documentation;

• force individuals through unreasonable procedures;

• create confusing forms;

• delay responses intentionally.

The exercise of rights should be as simple as possible.

Example

Poor facilitation A social media platform provides users with the following process:

1. Search website.
2. Locate privacy policy.
3. Find a hidden email address.
4. Submit a request.

5. Provide unnecessary government identification.

6. Wait several weeks for confirmation.

This creates barriers.

Better approach

The platform provides:

• a privacy dashboard;

• one-click access request;

• downloadable personal data;

• deletion option;

• objection mechanism.

This approach satisfies the facilitation principle.

16.2. Rights Should Be as Easy as Business Functions

Modern privacy compliance increasingly views data subject rights as part of user experience design.

Controllers already invest significant resources in making activities easy:

• purchasing products;

• changing passwords;

• updating profiles.

The same design principles should apply to privacy rights.

A user should be able to:

• download data;

• correct information;

• delete information;

• withdraw consent;

without unnecessary friction.

Example

Streaming platform A streaming service allows users to:

• change subscription;
• update payment information;
• cancel membership. However, deletion of personal data requires contacting customer support through multiple channels.

This creates an imbalance.

The GDPR expects deletion rights to be equally accessible.

17. Appropriate Communication Channels for Rights Requests

Article 12 does not prescribe one mandatory method for exercising rights.

Controllers should provide practical communication channels.

Examples

• email address;
• online form;
• privacy portal;
• customer service channel;
• postal communication. The controller cannot arbitrarily restrict individuals to a single method.

Example

A company states: “Data protection requests can only be submitted through this specific online form.” This may create difficulties for individuals who:

• cannot access the form;
• have disabilities;
• prefer written communication.

The controller should generally accept reasonable alternative methods.

18. Article 12(2) and Article 11 GDPR: Identification Problems

Article 12(2) refers to Article 11 GDPR.

Understanding the relationship between Articles 11 and 12(2) requires distinguishing:

Identification

Identification asks:

“Can the controller determine whose personal data is involved?”

Authentication

Authentication asks:

“Is the person making the request actually the person whose data is involved?”

These are different concepts.

18.1. Identification Problem - Article 11 GDPR

Article 11 applies where the controller processes personal data without needing to identify individuals.

Example

A website stores anonymous analytics information. A person writes: “Please provide all data you hold about me.” The controller cannot determine which data relates to that individual. This is an identification problem.

18.2. Authentication Problem - Article 12(6) GDPR

Authentication arises where the controller knows the data but needs to verify the requester.

Example

A bank receives: “Please provide my account statements.” The bank has the account information. However, it must ensure that the requester is actually the account holder. This is authentication.

19. Article 12(2): Controller Cannot Refuse Without Demonstration

Where Article 11(2) applies, the controller cannot simply reject a request.

The controller must demonstrate that:

• it genuinely cannot identify the individual;

• identification is objectively impossible.

This prevents controllers from using identification difficulties as an excuse to avoid compliance.

Example

A company stores customer information linked to:

• email address;
• account number;
• telephone number. A customer requests access using their registered email. The company cannot simply say:

“We cannot identify you.”

The company has sufficient information to connect the request with the customer.

20. Article 12(3): Response Timeline

Article 12(3) establishes one of the most operationally important GDPR obligations.

The controller must inform the data subject about action taken:

• without undue delay; and

• in any event within one month.

20.1. “Without Undue Delay”

The GDPR does not give controllers one month automatically.

The one-month period is the maximum deadline.

Controllers must act earlier where possible.

Example

A customer requests correction of an incorrect email address. The correction can be completed immediately. The controller cannot wait 30 days simply because the law allows one month.

20.2. Calculation of One-Month Period

The period begins when the controller receives the request.

Example

Request received: 10 January Deadline: 10 February If February has fewer days, the corresponding date applies under EU procedural rules.

21. Extension of Time Period

Article 12(3) permits extension by two additional months where necessary.

Therefore, the maximum possible period is:

1. month + 2 months = 3 months

However, extension is exceptional.

It requires consideration of:

1. complexity of request;

2. number of requests received.

Both factors are relevant.

Example

Valid extension A multinational company receives:

• 50,000 access requests following a major data breach. The company requires additional time to:
• collect information;
• verify records;

• review exemptions.

Extension may be justified.

Example

Invalid extension A company regularly receives five access requests per month. It claims: “Our compliance team is busy, therefore we require additional time.” This is unlikely to justify extension. Staff shortage is generally a failure of organisational planning.

22. Duty to Inform About Extension

Where an extension is required, the controller must inform the data subject:

• within one month;

• before expiry of the original deadline;

• explaining reasons for delay.

A controller cannot silently extend the deadline.

Example

Request received: 1 March By: 1 April Controller must either:

• provide response; or

• explain extension.

23. Electronic Requests and Electronic Responses

Article 12(3) provides that where the request is made electronically:

the response should also be provided electronically where possible.

This reflects practical digital reality.

Example

A user submits: “Download my personal data request” through an online privacy portal. The controller should generally provide:

• secure download link;
• electronic copy;

• digital format.

24. Article 12(4): Failure to Act on Requests

Article 12(4) prevents controllers from ignoring rights requests.

If a controller refuses to take action, it must inform the data subject:

1. without delay;

2. at the latest within one month;

3. reasons for refusal;

4. right to complain to supervisory authority;

5. right to seek judicial remedy.

24.1. No Silent Refusal

Silence is not permitted.

A controller cannot simply:

• ignore emails;

• delay indefinitely;

• fail to provide explanation.

Example

A customer requests deletion. The company refuses because:

• financial records must be retained under tax law. The company must explain: “We cannot delete your invoice records because legal obligations require retention. However, other unnecessary personal data will be erased.”

25. Relationship with Supervisory Authorities

The requirement to inform individuals about complaint mechanisms strengthens enforcement.

The data subject must know that refusal by a controller is not final.

They may:

• complain to a Data Protection Authority under Article 77;

• seek judicial remedy under Article 79.

26. Article 12(5): Free Exercise of Data Subject Rights

Article 12(5) establishes an important principle:

Information provided under Articles 13 and 14 and any communication and actions taken under Articles 15 to 22 and 34 shall be provided free of charge.

This provision reflects the GDPR's fundamental objective that data protection rights should be practically accessible to everyone.

If controllers were allowed to charge individuals every time they exercised their rights, many individuals would be discouraged from asserting their rights. Therefore, the GDPR adopts the principle that privacy rights are not commercial services.

A person should not have to pay:

• to know what personal data is processed;

• to correct inaccurate information;

• to request deletion;

• to object to processing;

• to receive breach information.

26.1. Scope of the Free-of-Charge Principle

Article 12(5) applies to:

(a) Information obligations

Including:

• Article 13, Information collected directly from data subjects;

• Article 14, Information obtained from third parties.

Example

A mobile application cannot charge users to view its privacy notice.

(b) Exercise of data subject rights

Including:

• access;

• rectification;

• erasure;

• restriction;

• portability;

• objection;

• automated decision-making rights.

(c) Personal data breach communication

Under Article 34 GDPR, controllers must communicate qualifying breaches to affected individuals.

Such communication cannot be conditional upon payment.

27. Exceptions: Manifestly Unfounded or Excessive Requests

Although rights are generally free, Article 12(5) recognises that controllers should not be required to repeatedly process abusive requests without limitation.

Therefore, where requests are:

1. manifestly unfounded; or

2. excessive, particularly because of repetitive character,

the controller may:

Option 1

Charge a reasonable fee.

OR

Option 2

Refuse to act on the request.

However, these exceptions are interpreted narrowly.

The GDPR places a strong presumption in favour of the data subject.

28. Manifestly Unfounded Requests

The term “manifestly unfounded” refers to requests that are clearly without legal basis or purpose.

The word “manifestly” is significant.

It means the lack of justification must be obvious.

Controllers cannot casually label inconvenient requests as unfounded.

Example

Clearly unfounded request A person who has never interacted with an organisation sends: “Provide me all my customer account information.” The organisation has no relationship, no account, and no personal data. After reasonable verification, the request may be considered unfounded.

Example

Not unfounded A customer requests access to all information held by an online platform. The platform argues: “The request is too broad.” This alone does not make the request unfounded. The GDPR does not require individuals to know exactly what information the controller holds.

29. Excessive Requests

The second exception concerns excessive requests.

Excessiveness generally refers to requests that impose disproportionate administrative burdens on controllers.

However, excessive does not simply mean:

• lengthy request;

• inconvenient request;

• expensive request.

The assessment requires consideration of the circumstances.

29.1. Repetitive Requests

Article 12(5) specifically mentions repetition.

Example

A user requests access every week for several years despite no changes in processing. Such behaviour may become excessive. However, repetition alone is not automatically excessive. The controller must consider:

• whether data has changed;
• whether processing activities changed;

• whether the individual has a legitimate reason.

Example

Legitimate repeated access A patient repeatedly requests medical records because:

• new medical information is added;
• treatment changes;
• healthcare decisions depend on updated information. Repeated requests are justified.

30. CJEU Interpretation of Excessive Requests

The Court of Justice of the European Union has emphasised that controllers must be cautious before refusing requests.

A request is not excessive merely because:

• it creates work;

• it is broad;

• the requester has another objective.

The controller must prove abusive conduct.

30.1. Request Purpose and Motivation

A major issue before courts has been whether a data subject must explain why they want their data.

The answer is:

Generally, no.

A data subject does not need to justify an access request.

Example

A person requests access because they want:

• to understand processing;
• to challenge a decision;
• to prepare litigation. The controller generally cannot reject the request merely because it suspects another purpose.

31. Burden of Proof Lies with Controller

Article 12(5) expressly states:

The controller shall bear the burden of demonstrating the manifestly unfounded or excessive character of the request.

This is a significant accountability requirement.

The controller must document:

• why the request was abusive;

• what facts support refusal;

• why less restrictive alternatives were insufficient.

Example

A company receives ten access requests from the same person. It cannot simply state: “Ten requests are excessive.” It must analyse:

• timing;
• similarity;

• circumstances;

• purpose;

• burden created.

32. Charging a Reasonable Fee

Where a request qualifies under Article 12(5), the controller may charge a reasonable fee.

However, the fee cannot become a profit mechanism.

The fee should reflect:

• administrative costs;

• duplication costs;

• processing costs.

Invalid approach

A company charges:

“€100 GDPR request processing fee.”

This would likely discourage rights exercise.

Potentially valid approach

A controller receives hundreds of identical requests from one individual requiring extensive manual work.

A limited administrative fee may be justified.

33. Refusal to Act

The controller may refuse to act where requests are manifestly unfounded or excessive.

However, refusal triggers Article 12(4).

The controller must explain:

• why action was refused;

• possibility of complaint;

• judicial remedies.

34. Article 12(6): Verification of Identity

Article 12(6) deals with situations where controllers have reasonable doubts regarding identity.

It provides:

Where the controller has reasonable doubts concerning the identity of the natural person making the request, it may request additional information necessary to confirm identity.

This provision balances two competing interests:

Protection of data subjects

Individuals must be able to exercise rights easily.

Protection against unauthorised disclosure

Controllers must not disclose personal data to strangers.

35. Identification vs Authentication - Critical Distinction

This distinction is essential in GDPR practice.

35.1. Identification

Identification asks:

“Can we locate the personal data belonging to this person?”

Example

A website stores browsing data linked only to random identifiers. A person says: “Give me all data about me.” The controller may not be able to identify the person.

35.2. Authentication

Authentication asks:

“Is this person really the person whose data we found?”

Example

A bank has all account records. A person emails: “Send me my account statements.” The bank knows the account exists but must verify identity.

36. Identity Verification Must Be Proportionate

Controllers cannot demand excessive identity information.

The principle of proportionality applies.

The controller should consider:

• sensitivity of data;

• risk of disclosure;

• existing authentication mechanisms;

• context of request.

Example

Low-risk request A user wants to unsubscribe from marketing emails. The controller should not demand:

• passport copy;
• biometric verification. An unsubscribe link may be sufficient.

Example

High-risk request A person requests:

• medical records;
• financial information;
• employment file. Stronger authentication may be justified.

37. Problems with Excessive Identity Requests

A common compliance mistake is requiring government identification for every GDPR request.

This may violate:

• data minimisation;

• facilitation obligation;

• proportionality.

Example

A user requests deletion of an online account. The company already knows:

• username;
• password;
• registered email. Demanding a passport scan may be excessive.

38. Authentication Methods

Appropriate methods may include:

• login authentication;

• verification code;

• confirmation email;

• security questions;

• existing account credentials.

The least intrusive effective method should generally be preferred.

39. Article 12(7): Standardised Icons

Article 12(7) introduces the possibility of using standardised icons with privacy information.

The purpose is to make complex processing information easier to understand.

Icons can communicate concepts quickly.

Examples

• location tracking;
• sharing with third parties;
• international transfers;
• profiling;
• retention periods.

39.1. Icons as a Supplement, Not Replacement

Icons cannot replace the privacy notice.

They supplement information.

A controller cannot simply display:

📍 Location 🤖 AI ☁ Cloud

and claim GDPR compliance.

The individual still requires detailed explanation.

Example

A fitness application may display: 📍 Location collected ❤️ Health data processed 🔄 Data shared with partners but must provide detailed explanations about:

• purposes;
• recipients;
• legal basis;

• retention.

40. Article 12(8): Commission Power Regarding Icons

Article 12(8) authorises the European Commission to adopt delegated acts determining:

• information represented by icons;

• procedures for using standardised icons.

However, standardised GDPR icons have not become practically established.

41. Article 12 GDPR and AI Governance

Article 12 has increasing importance in AI regulation.

Modern AI systems create transparency challenges because:

• decisions are automated;

• models are complex;

• processing is invisible;

• individuals may not understand consequences.

Article 12 requires controllers deploying AI systems to communicate:

• what AI does;

• why it is used;

• what data influences outcomes;

• how individuals can challenge decisions.

Example

AI credit scoring A bank uses AI to determine loan eligibility. A weak explanation: “Your application was assessed using automated systems.” This does not satisfy transparency. A better explanation:

“We use an automated scoring system that evaluates financial information, repayment history and account activity. The system generates a risk score. You may request human review and challenge the decision.”

42. Critical Evaluation of Article 12 GDPR

Article 12 represents one of the strongest transparency frameworks globally.

Its strengths include:

1. Moving beyond formal disclosure

The GDPR rejects the idea that privacy compliance equals providing a long document.

It focuses on meaningful understanding.

2. Empowering individuals

By requiring facilitation, Article 12 transforms rights from theoretical guarantees into practical tools.

3. Technology-neutral approach

The provision allows innovation:

• dashboards;

• AI assistants;

• interactive notices;

• visual explanations.

Limitations

1. Information overload remains a challenge

Even GDPR-compliant notices may remain lengthy because Articles 13 and 14 require extensive information.

2. Transparency does not always equal comprehension

Providing information does not guarantee that individuals understand complex processing.

3. AI creates new difficulties

Explaining machine learning systems in simple language remains challenging.