The General Data Protection Regulation transformed how organizations handle personal data across Europe and beyond. But here's the thing: most people trying to understand GDPR get lost in the legalese before they even scratch the surface.
This regulation contains 99 articles spread across 11 chapters. That's a lot to digest. And while every article serves a purpose, six stand out as particularly critical for businesses processing personal data of EU citizens. These articles form the backbone of data protection compliance and directly affect how companies collect, store, and use personal information.
What makes these six articles so important? They define the legal framework for processing activities, establish individual rights, and set expectations for organizational accountability. Get these wrong, and you're looking at potential fines reaching into the millions of euros.
Let's break down what actually matters.
Table of contents
- Article 6: Lawfulness of processing
- Article 13 and 14: Information obligations
- Article 15: Right of access
- Article 17: Right to erasure
- Article 28: Processor obligations
- Article 35: Data protection impact assessments
- Why these articles work together
- Implementing compliance across all six areas
Article 6: Lawfulness of processing
Article 6 answers the most fundamental question in GDPR compliance: when can you actually process someone's personal data?
The regulation identifies six lawful bases for processing. You need at least one of these to justify any processing activity:
Consent: The data subject gives clear permission for processing their personal data for a specific purpose. This needs to be freely given, specific, informed, and unambiguous. Pre-ticked boxes don't count. Neither does silence or inactivity.
Contract performance: Processing is necessary to fulfill a contract with the individual, or to take steps before entering into a contract at their request. If someone orders a product from your website, you can process their delivery address to ship that product.
Legal obligation: You must process the data to comply with a law. Tax records fall into this category. So do certain employment records.
Vital interests: Processing is necessary to protect someone's life. This applies in medical emergencies and similar situations where someone's physical safety is at risk.
Public task: The processing is necessary for a task carried out in the public interest or in the exercise of official authority. This mostly applies to public bodies and government organizations.
Legitimate interests: Processing is necessary for your legitimate interests or those of a third party, unless those interests are overridden by the individual's rights and freedoms. This is the most flexible basis but requires careful balancing of interests.
Choosing the right lawful basis matters tremendously. You can't just pick whichever one seems convenient. Each basis comes with specific requirements and limitations. If you rely on consent, individuals can withdraw it at any time. If you use legitimate interests, you need to conduct a balancing test and document your reasoning.
Public authorities can't use legitimate interests as a basis when processing data for their official tasks. That's explicitly ruled out.
Many organizations make the mistake of relying on consent when another basis would be more appropriate. Consent sounds simple, but it's actually one of the harder bases to implement correctly. The bar for valid consent is high. Really high.
Article 6 also addresses repurposing data. If you collected personal data for one purpose and now want to use it for something else, you need to check whether that new purpose is compatible with the original one. The regulation provides factors to consider: the link between purposes, the context of collection, the nature of the data, possible consequences for individuals, and whether appropriate safeguards exist.
Article 13 and 14: Information obligations
Transparency sits at the heart of GDPR. Articles 13 and 14 spell out exactly what information you must provide to individuals when collecting their personal data.
Article 13 applies when you collect data directly from the individual. Think contact forms, account registrations, newsletter signups. Article 14 covers situations where you obtain personal data from another source instead of directly from the person.
Both articles require you to provide specific information at the point of collection (or within a reasonable period afterward if obtained indirectly). This isn't optional disclosure buried in a privacy policy. This is upfront, clear communication about what you're doing with someone's data.
The required information includes:
- Your identity and contact details
- Your data protection officer's contact details (if you have one)
- The purposes of processing and the lawful basis
- Legitimate interests (if you're relying on that basis)
- Categories of personal data (for Article 14 situations)
- Recipients or categories of recipients of the data
- Details about international transfers
- Retention periods or criteria for determining them
- Individual rights (access, rectification, erasure, restriction, objection, data portability)
- The right to withdraw consent (if applicable)
- The right to lodge a complaint with a supervisory authority
- Whether providing data is a statutory, contractual, or necessary requirement
- Information about automated decision-making and profiling
That's a substantial list. And you need to provide all of this in a concise, transparent, intelligible, and easily accessible form. Use clear and plain language. No legal jargon that requires a law degree to decipher.
Privacy policies serve as the primary vehicle for meeting these transparency obligations. But a privacy policy alone isn't always enough. If you're collecting data through a specific form or interaction, you might need additional notices at that collection point.
Layered notices work well for many organizations. Provide key information upfront where the data is collected, then link to your full privacy policy for additional details. This approach balances completeness with usability.
The timing requirements differ slightly between Articles 13 and 14. For directly collected data (Article 13), you must provide the information at the time you obtain the data. For indirectly collected data (Article 14), you have up to one month, or you must provide it when you first contact the individual or disclose the data to another recipient, whichever comes first.
Some exceptions exist for Article 14. You don't need to provide the information if the individual already has it, providing it would be impossible or require disproportionate effort, obtaining or disclosure is expressly laid down by law, or the data must remain confidential due to professional secrecy obligations.
Article 15: Right of access
Data subjects have the right to know whether you're processing their personal data. If you are, they can request access to that data and obtain a copy.
This right, established in Article 15, gives individuals significant insight into how organizations use their information. When someone submits an access request (often called a subject access request or SAR), you must respond within one month. That deadline can be extended by two more months for complex requests, but you need to inform the requester within the first month and explain why the extension is needed.
The response must include:
- Confirmation that you're processing their personal data
- The purposes of processing
- The categories of personal data involved
- The recipients or categories of recipients
- The retention period or criteria for determining it
- Information about their rights (rectification, erasure, restriction, objection)
- The right to lodge a complaint with a supervisory authority
- Information about the source of the data (if not collected directly from them)
- Details about automated decision-making or profiling
- Safeguards for international transfers
You also need to provide a copy of the personal data being processed. The first copy must be free. If the individual requests additional copies, you can charge a reasonable fee based on administrative costs.
The format for providing information deserves consideration. The regulation states that information should generally be provided in writing or by electronic means. If the request was made electronically, provide the information in a commonly used electronic format unless the person requests otherwise.
Verifying identity becomes critical with access requests. You need to ensure you're disclosing personal data to the right person. But you can't demand excessive information for verification. The approach should be proportionate. If you already have a relationship with the requester and they're submitting the request through an authenticated account, that might suffice. For requests from unknown individuals, you may need additional identification.
Manifestly unfounded or excessive requests (particularly repetitive ones) allow you to charge a reasonable fee or refuse to act. But that's an exception, not the rule. You need to demonstrate why a request falls into this category.
Some organizations struggle with the scope of access requests. Do you need to search every email account, every system, every backup? The regulation requires you to provide information about personal data being processed. Backup copies kept solely for disaster recovery purposes, where the data isn't actively processed, might not need to be searched. But actively used systems certainly do.
Article 17: Right to erasure
The right to erasure, often called the "right to be forgotten," allows individuals to request deletion of their personal data under specific circumstances.
This right isn't absolute. Data subjects can request erasure when:
- The personal data is no longer necessary for the purposes it was collected
- They withdraw consent and there's no other legal ground for processing
- They object to processing and there are no overriding legitimate grounds
- The personal data was unlawfully processed
- Erasure is required for compliance with a legal obligation
- The personal data was collected in relation to information society services offered to children
You must respond to erasure requests within one month, the same timeline as access requests. But here's where it gets interesting: you don't have to comply with every erasure request.
Several grounds allow you to refuse:
- Exercising the right to freedom of expression and information
- Compliance with a legal obligation requiring processing
- Performance of a task carried out in the public interest or exercise of official authority
- Public health purposes
- Archiving, research, or statistical purposes (with appropriate safeguards)
- Establishment, exercise, or defense of legal claims
Legal obligations often provide grounds to retain data despite an erasure request. Tax authorities require businesses to keep financial records for specified periods. Employment laws mandate retention of certain employee records. You can refuse erasure when these obligations apply.
The regulation also requires reasonable steps to inform other controllers about erasure requests if you've disclosed the personal data to them. This creates a ripple effect. If you shared someone's data with third parties and that person exercises their right to erasure, you need to tell those third parties about the request so they can also erase the data (unless that's impossible or requires disproportionate effort).
Backup systems present challenges for erasure. You don't need to delete data from backups immediately if those backups are isolated and not used for active processing. But when you restore from a backup, the erased data should not be restored into active systems.
Documentation matters tremendously with erasure requests. Record the request, your decision, and your reasoning. If you refuse erasure, explain which exemption applies and why.
Article 28: Processor obligations
Article 28 governs the relationship between data controllers and data processors. If you use third-party services that process personal data on your behalf, this article applies to you.
Controllers maintain overall responsibility for processing activities. Processors act on the controller's instructions. But processors aren't off the hook. They have direct obligations under GDPR.
The regulation requires a written contract (or other legal act) between controllers and processors. This contract must include specific terms:
Processing instructions: The processor can only process data on documented instructions from the controller, including transfers to third countries.
Confidentiality: People authorized to process the data must be under confidentiality obligations.
Security measures: The processor must implement appropriate technical and organizational measures.
Sub-processor conditions: The processor needs the controller's authorization (general or specific) before engaging sub-processors. The processor remains liable to the controller for the sub-processor's performance.
Assistance obligations: The processor must assist the controller in responding to data subject rights requests and meeting security, breach notification, and impact assessment obligations.
Data handling at contract end: The processor must delete or return all personal data after services end, unless law requires storage.
Audit rights: The processor must make information available to demonstrate compliance and allow audits.
These requirements create a framework that allocates responsibilities and ensures accountability throughout the processing chain. Controllers can't just hand off data to a processor and wash their hands of compliance. They must choose processors that provide sufficient guarantees of GDPR compliance and monitor that compliance throughout the relationship.
Processors face potential liability for GDPR violations. If a processor processes data outside the controller's instructions or fails to meet its obligations, it can be held directly liable. The regulation treats the processor as a controller for that processing activity.
Many cloud service providers, SaaS platforms, and outsourced service providers function as processors. If they process personal data as part of their service but don't determine the purposes and means of processing, they're processors. Understanding this distinction affects contractual relationships and compliance obligations.
One area that trips up many organizations: sub-processors. If your processor uses another company to provide part of the service (and that company will process personal data), you need visibility into that relationship. The processor needs your permission before engaging sub-processors. Many controllers provide general authorization subject to notification requirements, allowing processors to change sub-processors if they notify the controller and give them an opportunity to object.
Article 35: Data protection impact assessments
When processing operations are likely to result in high risk to individuals' rights and freedoms, Article 35 requires a data protection impact assessment (DPIA) before processing begins.
This isn't a compliance checklist exercise. A proper DPIA involves systematic assessment of risks, evaluation of measures to address those risks, and consideration of whether the processing should proceed at all.
The regulation identifies scenarios where a DPIA is required:
- Systematic and extensive evaluation of personal aspects based on automated processing (including profiling) that produces legal or similarly significant effects
- Large-scale processing of special categories of data or data relating to criminal convictions
- Systematic monitoring of publicly accessible areas on a large scale
Supervisory authorities publish lists of processing operations requiring DPIAs. They can also publish lists of operations that don't require DPIAs. Check your relevant supervisory authority's guidance.
"High risk" depends on various factors. The Article 29 Working Party (now the European Data Protection Board) identified nine criteria, any two of which typically indicate high risk:
- Evaluation or scoring
- Automated decision-making with legal or similar significant effect
- Systematic monitoring
- Sensitive data or data of a highly personal nature
- Data processed on a large scale
- Matching or combining datasets
- Data concerning vulnerable data subjects
- Innovative use of new technological or organizational solutions
- Processing that prevents data subjects from exercising a right or using a service or contract
A DPIA must contain:
- A systematic description of the processing operations and purposes
- An assessment of necessity and proportionality
- An assessment of risks to individuals' rights and freedoms
- Measures to address those risks and demonstrate compliance
The assessment needs to be meaningful. Template DPIAs that organizations fill out without genuine analysis don't meet the requirement. You need to actually think through what could go wrong, who might be affected, and how to prevent or mitigate those outcomes.
Data protection officers (when appointed) must be consulted during DPIA preparation. Data subjects or their representatives should be consulted when appropriate.
If the DPIA indicates high risk that you can't adequately mitigate, you must consult the supervisory authority before processing. The authority will provide written advice within eight weeks (extendable to 14 weeks for complex cases).
DPIAs aren't one-time exercises. You should review and update them when there are changes to the risk or nature of processing operations. Regular reviews ensure your risk assessment remains current.
Many organizations find DPIAs valuable beyond compliance. The process of systematically examining processing activities, identifying risks, and determining mitigation measures improves data protection practices. It forces consideration of privacy implications before deployment rather than retrofitting protections after problems emerge.
Why these articles work together
These six articles don't exist in isolation. They form an interconnected framework that governs different aspects of data protection.
Article 6 provides the foundation by establishing when processing is lawful. Without a lawful basis, you can't process personal data at all. Articles 13 and 14 build on this by requiring transparency about that processing. Individuals need to understand what you're doing with their data and why.
Articles 15 and 17 give individuals mechanisms to exercise control. Access requests let people see what data you hold. Erasure requests let them demand deletion under appropriate circumstances. These rights only make sense in the context of Articles 6, 13, and 14. You can only access or delete data that's being lawfully processed, and you need transparency information to understand whether to exercise these rights.
Article 28 extends accountability beyond single organizations. Most modern businesses rely on third-party processors. This article ensures that responsibility doesn't disappear when data moves to a processor.
Article 35 requires proactive risk assessment for high-risk processing. This connects back to all the other articles. The lawful basis you choose under Article 6 affects risk assessment. The information you provide under Articles 13 and 14 can mitigate certain risks. Individual rights under Articles 15 and 17 might be risk mitigation measures. Processor arrangements under Article 28 introduce additional risks that need assessment.
Consider a practical example. An e-commerce business wants to implement a new recommendation engine using customer purchase history and browsing behavior. Here's how these articles interact:
Article 6 comes first. The business needs a lawful basis. Consent might work, but legitimate interests could be more appropriate if recommendations improve customer experience and aren't intrusive.
Articles 13 and 14 require updating the privacy policy to explain the recommendation system, what data it uses, and the lawful basis. Customers need this information to understand how their data is being used.
If the recommendation engine involves automated decision-making with significant effects, Article 35 requires a DPIA. The business needs to assess risks like filter bubbles, discriminatory outcomes, or privacy intrusion from profiling.
Article 28 becomes relevant if a third-party provider hosts or operates the recommendation engine. The business needs appropriate processor contracts in place.
Articles 15 and 17 affect operational processes. The business must be able to retrieve recommendation data for access requests and delete it for valid erasure requests.
Implementing compliance across all six areas
Theory is one thing. Implementation is another. Organizations need practical systems and processes to comply with these articles.
Start with Article 6. Document your lawful basis for each processing activity. Create a processing register that maps data types, purposes, lawful bases, and retention periods. This becomes your roadmap for compliance across other articles.
For Articles 13 and 14, develop a comprehensive but readable privacy policy. But don't stop there. Create point-of-collection notices for forms, apps, and other data collection points. Make transparency layered and contextual.
Build request handling procedures for Articles 15 and 17. Who receives requests? How do you verify identity? What systems need to be searched? How do you compile responses? What's the escalation process for edge cases? Document all of this before you receive your first request.
Article 28 compliance requires contract management. Review existing processor contracts. Do they include required terms? If not, negotiate amendments. For new processors, use contract templates that include all mandatory clauses. Maintain a register of processors and sub-processors.
Establish a DPIA process for Article 35. Create templates, but ensure they encourage genuine analysis rather than box-checking. Define triggers that indicate when a DPIA is needed. Involve appropriate stakeholders, including your data protection officer if you have one.
Training matters across all six articles. Staff need to understand lawful bases, transparency obligations, individual rights, processor requirements, and when DPIAs are needed. Different roles need different levels of knowledge, but everyone who handles personal data needs baseline awareness.
Technology can help, but it's not a complete solution. Privacy management platforms can track processing activities, manage consent, handle requests, and document DPIAs. But these tools require proper configuration, accurate data, and human judgment. (More on that in a moment.)
Regular audits catch compliance gaps. Review your Article 6 documentation annually. Check whether privacy notices accurately reflect current processing. Test request handling procedures. Examine processor contracts when renewals approach. Update DPIAs when processing changes.
One pattern that emerges: documentation is everything. The regulation explicitly requires documentation in many places, but even where it doesn't, documentation proves compliance. If a supervisory authority investigates, you need evidence that you've met your obligations. Verbal assurances don't cut it.
Achieving comprehensive compliance across these six articles requires dedicated resources. Many organizations appoint data protection officers to coordinate these efforts. Even when not legally required to appoint a DPO, having someone responsible for data protection makes practical sense.
Compliance software like ComplyDog helps companies meet GDPR requirements across all six of these critical articles. These platforms centralize documentation, automate routine tasks, and provide workflows for handling requests and conducting assessments. By bringing together Article 6 lawful basis tracking, Article 13/14 privacy notice management, Article 15/17 request handling, Article 28 processor documentation, and Article 35 DPIA tools, compliance platforms give organizations a systematic approach to data protection that reduces risk and administrative burden while ensuring nothing falls through the cracks.
