If you have ever opened the GDPR and felt lost in legal wording, you are not alone. The Regulation is detailed by design, but most compliance decisions come down to a handful of core Articles that explain what you can do with personal data, what you must tell people, and what you need to do when things go wrong.
This guide breaks down the key GDPR Articles in plain English, with practical examples for organisations that may operate in Jamaica while serving EU customers, employing EU residents, or handling EU personal data through websites, apps, cloud tools, or international partners.
Note: This is general information, not legal advice. GDPR obligations can turn on your exact facts, data flows, and contracts.
First, what the GDPR actually is (Articles vs Recitals)
The GDPR is EU law: Regulation (EU) 2016/679. You can read the official text on EUR-Lex.
Articles are the binding rules.
Recitals are explanatory notes that help interpret the Articles.
When people say “GDPR Article X,” they usually mean a specific obligation or right you must be able to demonstrate in practice.
Does the GDPR apply to a Jamaican business?
Sometimes, yes. Even if you are not established in the EU, the GDPR can apply if you:
Offer goods or services to people in the EU (even if you do not charge).
Monitor behaviour in the EU, for example via tracking, profiling, or targeted advertising.
In addition, many Jamaican organisations choose to align with GDPR concepts because clients, banks, and international counterparties often expect GDPR-style governance.
GDPR basics in plain English: the “big rocks”
Before the Article-by-Article breakdown, it helps to anchor on four themes the GDPR repeats throughout:
Be fair and transparent about what you do with personal data.
Have a lawful reason to process it.
Secure it and limit access.
Be able to prove compliance (documentation and governance).
Key GDPR Articles explained (with what they mean in practice)
Below is a practical map of the Articles that most often matter in real-world compliance reviews, contract negotiations, incident response, and customer requests.
GDPR Article(s) | Plain English meaning | What to do in practice |
Art. 4 | Key definitions (personal data, processing, controller, processor) | Confirm whether you are the “controller” (deciding purpose/means) or “processor” (acting on instructions) for each activity |
Art. 5 | Data protection principles | Build processes that support minimisation, accuracy, storage limits, security, and fairness |
Art. 6 | Lawful bases for processing | Match each processing purpose to a lawful basis (contract, legal obligation, legitimate interests, consent, etc.) |
Art. 7 | Conditions for consent | If you rely on consent, make it clear, specific, and easy to withdraw |
Art. 9 | Special category data (sensitive data) | Treat health, biometrics, religion, etc. as higher risk and ensure an Article 9 condition applies |
Art. 12 to 14 | Transparency duties (privacy notices) | Provide understandable notices that explain what you collect, why, retention, sharing, rights, and contacts |
Art. 15 to 22 | Individual rights (access, deletion, objection, portability, etc.) | Build an intake and response process with deadlines, identity verification, and logging |
Art. 24 to 25 | Accountability, privacy by design/default | Bake privacy controls into systems and policies, not just a one-time notice |
Art. 28 | Processor obligations and contracts | Use proper data processing agreements (DPAs) with vendors, cloud providers, and outsourcing partners |
Art. 30 | Records of processing activities | Maintain an internal data map (what, why, where, who, retention, security) |
Art. 32 to 34 | Security and breach notification | Implement appropriate security, assess incidents quickly, notify regulators and affected people when required |
Art. 35 | Data Protection Impact Assessments (DPIAs) | Do DPIAs for high-risk projects like large-scale monitoring or sensitive data processing |
Art. 44 to 49 | International data transfers | Use valid transfer mechanisms if EU data is sent outside the EU |
Art. 83 | Administrative fines | Understand that penalties can be severe, especially for serious or repeated breaches |
Article 4: the definitions that drive everything
Article 4 is where “personal data” and “processing” are defined broadly. In practice:
If data can identify someone directly or indirectly (name, ID, email, device ID, location data), it is usually personal data.
If you do almost anything with it (collect, store, view, share, delete), that is processing.
The controller vs processor distinction matters because controllers carry the primary burden for transparency, lawful bases, and rights handling.
Article 5: the principles (your compliance north star)
Article 5 principles are often what regulators cite when something “feels wrong,” even if a specific technical requirement was met.
In plain English, you should:
Collect only what you need.
Use it only for stated purposes.
Keep it accurate.
Keep it no longer than necessary.
Secure it.
Be able to prove all of the above.
Article 6: lawful bases (pick the right reason, not the convenient one)
Article 6 requires that each processing activity has a lawful basis. The most common are:
Contract: You need the data to deliver what the person asked for.
Legal obligation: You must process due to a legal requirement.
Legitimate interests: You have a genuine business reason that is not overridden by the person’s rights (and you have assessed the balance).
Consent: The person clearly agreed.
A practical example: if a customer books an airport transfer online, processing their name, pickup location, and flight number is usually contract-based. Many booking platforms in travel and transport also post detailed privacy notices and user rights information (for example, Grand Limousine’s nationwide booking and airport car service site includes privacy and reservation context that illustrates the kind of transparency users expect when sharing travel details).
Article 7: consent must be real (and easy to withdraw)
If you rely on consent, Article 7 expects that you can prove it and that withdrawal is as easy as giving it.
In plain English:
No pre-ticked boxes.
No “take it or leave it” consent for processing that is not necessary.
Keep records of when and how consent was obtained.
Article 9: sensitive data has extra rules
Article 9 covers “special category” data, such as health data and biometrics.
In practice, if your organisation collects medical info for insurance, HR, wellness programmes, or access control systems, you generally need:
An Article 6 lawful basis, and
An additional Article 9 condition (for example, explicit consent or specific employment/health law grounds, depending on the context).
Articles 12 to 14: privacy notices should answer real questions
These Articles are why privacy notices exist. They require information to be provided in a concise, transparent, intelligible and easily accessible form.
A strong notice (and the internal reality behind it) typically covers:
What personal data you collect
Why you collect it (purposes)
Your lawful bases
Who you share it with (and why)
How long you keep it
How to exercise rights
International transfers, if any
Articles 15 to 22: the rights people can actually use
These Articles are where compliance becomes operational.
Key rights in plain English:
Article 15 (Access): “Show me what data you have about me.”
Article 16 (Rectification): “Fix inaccurate data.”
Article 17 (Erasure): “Delete my data” (not absolute, there are exceptions).
Article 18 (Restriction): “Pause using my data while an issue is resolved.”
Article 20 (Portability): “Give me my data in a usable format, so I can move it.”
Article 21 (Objection): “Stop processing based on legitimate interests” (subject to your compelling grounds).
Article 22 (Automated decisions): Limits on decisions made solely by automated processing in certain cases.
Operationally, organisations often struggle with identity verification, deadlines, and retrieving data from multiple systems. The solution is usually a documented workflow, a log, and clear system ownership.
Articles 24 and 25: “accountability” and privacy by design
These Articles are the GDPR’s management system.
Article 24 expects you to implement appropriate measures and be able to demonstrate them.
Article 25 expects privacy by design and default, meaning you configure systems to collect the minimum data and restrict access unless there is a justified need.
A practical takeaway: if your default settings expose too much personal information, or your forms collect “nice to have” fields, you are starting from a weak position.
Article 28: your vendors can create GDPR risk
If a third party processes personal data for you (cloud hosting, payroll, CRM, call centre, IT support), Article 28 expects a proper contract with specific clauses.
At a minimum, you typically want contractual clarity on:
Instructions and purpose limits
Confidentiality and access controls
Subprocessors (who else they use)
Security measures
Assistance with rights requests and breaches
Deletion or return of data at end of service
Article 30: records of processing (your internal data map)
Article 30 does not mean “write a long GDPR policy and file it away.” It means you can answer, quickly and accurately:
What data you have
Where it came from
Where it goes
Who can access it
How long you keep it
What security applies
This record is also what makes breach response and rights requests realistic.
Articles 32 to 34: security and breach notification
Article 32 is about implementing appropriate security, considering risk. The GDPR does not mandate a single checklist, but expects measures proportionate to sensitivity, scale, and threat.
Article 33 requires notifying the supervisory authority of certain personal data breaches (generally within 72 hours of becoming aware).
Article 34 may require notifying affected individuals when the breach is likely to result in a high risk to their rights and freedoms.
Practical lesson: you need an incident response plan that includes legal, IT, leadership, and communications, plus a way to document decisions.
Article 35: DPIAs (assess high-risk projects before launch)
A Data Protection Impact Assessment is required for certain high-risk processing.
In plain English, if you are rolling out something that could significantly affect individuals (large-scale profiling, systematic monitoring, large-scale sensitive data), do a DPIA early enough to change the design.
Guidance on DPIAs and other GDPR concepts is frequently discussed by regulators and the European Data Protection Board (EDPB).
Articles 44 to 49: cross-border transfers
If EU personal data is transferred outside the EU/EEA, these Articles require specific mechanisms and safeguards.
This is often where international groups and service providers need careful legal review, especially when data flows through multiple jurisdictions and vendors.
Article 83: fines (and why governance matters)
Article 83 empowers regulators to impose significant fines depending on the type of infringement, seriousness, duration, intent, and mitigation.
Even where fines are not the primary concern, GDPR investigations can create business disruption, reputational damage, and contractual fallout.
A quick “plain English” GDPR readiness check
If you want a practical starting point, sanity-check whether you can answer these questions without guesswork:
Do we know what personal data we collect, where it sits, and who can access it?
For each purpose, do we have a lawful basis and can we explain it simply?
Do our privacy notices match what we actually do?
Can we reliably respond to access, deletion, and objection requests?
Do we have written contracts in place for vendors that process data for us?
Do we have an incident response plan and breach decision log?
GDPR and Jamaica’s Data Protection Act (why alignment still matters)
Jamaica has its own data protection framework, including the Data Protection Act, 2020. While GDPR and Jamaican law are not identical, they share common themes: accountability, transparency, security, and individual rights.
For organisations that touch EU data (or do business with EU-facing partners), understanding the GDPR Articles can help you:
Meet international expectations in contracts and audits
Build stronger internal governance for privacy and cyber risk
Reduce friction when expanding into EU markets
Frequently Asked Questions
What are the most important GDPR Articles to know first? Articles 5 (principles), 6 (lawful bases), 12 to 14 (transparency), 15 to 22 (rights), 28 (processors), and 32 to 34 (security and breaches) cover most day-to-day compliance.
Does GDPR apply if my company is based in Jamaica? It can, if you offer goods or services to people in the EU or monitor behaviour in the EU. Even when it does not legally apply, many organisations align to GDPR-style standards for commercial and risk reasons.
Is consent always required under GDPR? No. Consent is only one lawful basis. Many business activities rely on contract, legal obligation, or legitimate interests, depending on the context.
What is a “controller” vs a “processor”? A controller decides why and how personal data is processed. A processor processes personal data on the controller’s documented instructions (for example, a cloud service provider hosting customer data).
What happens if there is a data breach? You must assess the risk quickly, secure systems, document the incident, and determine whether notification to a regulator and affected individuals is required under Articles 33 and 34.
Need help translating GDPR rules into workable policies and contracts?
If your organisation handles international personal data, the hardest part is rarely the text of the GDPR, it is building processes that hold up under real pressure: vendor onboarding, cross-border transfers, employee access, and breach response.
Henlin Gibson Henlin advises clients on data privacy, compliance and risk governance. To discuss a GDPR-focused review of your privacy notices, data processing agreements, incident readiness, or cross-border data flows, contact Henlin Gibson Henlin.