If you work with customer lists, employee records, CCTV footage, online forms, or marketing databases, compliance under Jamaica’s Data Protection Act starts with one deceptively simple question: is this “personal data”? The answer determines whether you need a lawful basis for processing, what security safeguards are required, what you must disclose in privacy notices, and how you respond to access requests or incidents.
This guide breaks down what typically counts as personal data, what usually does not, and the grey areas that commonly catch organisations in Jamaica by surprise.
Why the “personal data” definition matters
The Data Protection Act is triggered by the processing of personal data. In practical terms, that definition drives your obligations around:
Transparency (what you must tell people about collection and use).
Purpose limitation and data minimisation (collect what you need, use it for stated purposes).
Security (technical and organisational measures that match the sensitivity and risk).
Data subject rights (for example, requests for access, correction, or deletion where applicable).
Third parties and outsourcing (contracts, due diligence, and controls when vendors process data for you).
Misclassifying data is a common root cause of compliance gaps, especially where organisations assume “it’s just a number,” “it’s public,” or “it’s company information so it’s not personal.”
The core test: “information relating to an identified or identifiable individual”
While exact wording and scope should always be checked against the Act itself (see Jamaica Laws Online), the central idea in modern data protection regimes is consistent: personal data is information that relates to a living person who is identified, or could reasonably be identified, from that data alone or together with other information.
Two parts of that test matter in practice.
1) “Identified” or “identifiable”
Identified is straightforward: the information clearly points to a specific person (for example, a named customer file).
Identifiable is broader: even if a name is not present, a person can be singled out or linked using other data that you or someone else is likely to have.
Examples of data that can make someone identifiable include:
A unique customer number used consistently across systems.
Location data that shows a regular home and work pattern.
A combination of details (job title + workplace + parish + photo) that narrows to one person.
Identification is context-specific. A data point might be non-identifying in one setting, but identifying in another when combined with additional fields.
2) “Relating to” the individual
Data “relates to” a person not only when it describes them (for example, age, address, medical status), but also when it is used to make decisions about them (for example, risk scores, credit decisions, disciplinary notes, watch lists, fraud flags).
This is why internal notes, tags, ratings, or “do not serve” labels can still be personal data.
Common examples: what usually counts as personal data
The following categories are frequently personal data because they identify a person directly or indirectly:
Direct identifiers: full name, TRN (where used to identify an individual), passport number, driver’s licence number, National Insurance information (where applicable), signature.
Contact information: personal phone number, personal email, home address.
Online and device identifiers: IP address (in many contexts), device IDs, cookie identifiers, mobile advertising IDs, account usernames.
Images and recordings: CCTV footage, photos, voice recordings (especially where a person can be recognised).
Employment information: employee ID tied to a staff profile, payroll data, performance reviews, disciplinary records.
Financial and transactional information: bank account details, card details, transaction history linked to a person, invoices issued to an individual.
Location data: GPS records, delivery locations when tied to a person, commute patterns.
Special categories (sensitive personal data): handle with extra care
Most data protection laws treat some types of personal data as higher-risk and impose stricter conditions for processing. While you should confirm the categories and conditions that apply under Jamaica’s Data Protection Act, organisations should generally assume heightened sensitivity around:
Health and medical information.
Biometric data used for identification (for example, fingerprints, facial recognition templates).
Information revealing racial or ethnic origin, religious or similar beliefs, or political opinions.
Sexual life or sexual orientation.
Criminal allegations or convictions (often regulated with particular care).
If your processing involves these areas, it is wise to get legal advice early, because the lawful basis, notice wording, retention, access controls, and incident response expectations are typically stricter.
What usually does not count as personal data (and the important caveats)
Some information falls outside the definition of personal data, but only when it genuinely cannot be tied back to an individual.
Truly anonymised data
Anonymised data is data that has been irreversibly de-identified so that no individual can be identified by any party using reasonably available means.
Key caveat: If there is a realistic way to re-identify people (for example, through a key file, or by combining with other datasets), then it is not anonymised.
Aggregated statistics
A report such as “30% of customers in Kingston chose delivery” is typically not personal data if it is sufficiently aggregated.
Key caveat: Small sample sizes can undo aggregation. A statistic like “the only employee in a specific role took medical leave” can effectively identify someone.
Purely corporate information
Information about a company (for example, a company’s registered office, general switchboard number, or corporate bank account) is not necessarily personal data.
Key caveat: Many “business” details become personal when tied to individuals, such as:
A sole trader’s business phone number that is also their personal number.
“info@company.com” (often not personal) versus “firstname.lastname@company.com” (often personal).
A small company where a role title effectively points to a single person.
Role-based contact details (sometimes)
Emails like “support@”, “accounts@”, or “hr@” may not be personal data where they are genuinely role-based.
Key caveat: If the mailbox is effectively operated by one identifiable person and used as their direct identifier in practice, treat it cautiously.
Pseudonymised vs anonymised: one still counts as personal data
A frequent misunderstanding is believing that “removing names” makes data non-personal.
Pseudonymised data (for example, replacing names with a customer ID, or hashing emails while keeping a consistent identifier) often remains personal data, because the person can still be singled out or re-identified using additional information.
Anonymised data, done properly, may fall outside personal data.
If you can link a record back to a person via a lookup table, internal CRM, or other dataset, you should assume it is personal data.
Grey areas that commonly surprise organisations
These are some of the most common “we didn’t think that was personal data” scenarios.
CCTV and access control logs
CCTV is personal data where individuals are identifiable. The same goes for:
Visitor logs.
Badge access records.
Time and attendance systems.
Even if you do not know the person’s name, the footage may allow identification.
IP addresses, cookies, and marketing identifiers
Online identifiers can be personal data depending on how they are used and whether they can be linked to a person. This is especially relevant for:
Website analytics.
Ad retargeting.
App telemetry and crash reports.
If an identifier is used to profile, single out, or track a user over time, treat it as personal data.
“Public” information
Public availability does not automatically remove data protection obligations. Public social media posts, public directories, or publicly accessible registers may still contain personal data.
The key compliance question usually shifts from “is it personal data?” to “what lawful basis and notice obligations apply, and is the use fair and proportionate?”
Internal opinions and notes
Manager notes, customer service comments, risk flags, and complaint records can be personal data, especially where they influence decisions about the person.
Photographs and voice recordings
Photos, voice notes, call recordings, and video testimonials are typically personal data if a person can be identified.
Quick reference table: what counts and what doesn’t (in many real-world contexts)
Data item | Usually personal data? | Why it matters | Common pitfall |
Full name + phone number | Yes | Directly identifies a person | Stored in marketing lists without clear notice or consent where required |
Customer account number | Often yes | Can single out a person in your systems | Treated as “not personal” because it is “just a number” |
Maybe | Could be role-based rather than individual | Used as a proxy for one staff member in practice | |
Often yes | Tied to an identifiable person | Shared externally without considering privacy notice and purpose | |
CCTV footage in reception | Often yes | Identifies visitors and staff | No signage, excessive retention, broad access |
Aggregated sales by parish | Often no | Not linked to individuals | Small groups make people identifiable |
Hashed email used for ad matching | Often yes | Still enables consistent tracking | Assumed anonymous because it is hashed |
Company registration number | Often no | Identifies an entity, not a person | Linked to sole traders or directors in a way that identifies individuals |
Health note in HR file | Yes (likely sensitive) | Higher risk category | Stored in general HR folders with broad access |
This table is a practical guide, not a substitute for legal advice. Classification depends on context, linkability, and the way the information is used.
A practical way to decide: three questions to ask your team
When you are unsure whether a dataset is personal data, ask:
Can we identify a person directly from this data (name, image, government ID, personal contact details)?
Could we identify them indirectly by combining it with other information we already have (CRM, HR system, logs, third-party data)?
Are we using it to make decisions about someone, track them, or treat them differently?
If the answer is “yes” to any of the above, treat it as personal data and apply the Act’s controls.
What to do next: turning classification into compliance
Once you know what personal data you hold, the next step is operational.
Build (or refresh) a data inventory
Map what you collect, where it sits, who can access it, how long you retain it, and which vendors touch it. This exercise is also where “shadow” spreadsheets and informal WhatsApp/email workflows often come to light.
Align notices, contracts, and retention with reality
Privacy notices and internal policies often drift away from actual practice. Ensure your documentation matches:
The purposes you are actually using the data for.
The categories of people affected (customers, employees, contractors, minors).
The retention period that makes sense for legal, regulatory, and dispute risk.
Treat “not personal data” claims as a risk decision
If the business wants to treat a dataset as non-personal (for example, “anonymised analytics”), document the rationale and test it. Re-identification risk is not theoretical, it is one of the most common failure points in privacy programmes.
When legal advice is particularly useful
Consider getting advice where the stakes are higher or the rules are less intuitive, including:
New marketing initiatives that rely on tracking or profiling.
Cross-border transfers and vendor arrangements.
Employee monitoring, CCTV, or access control systems.
Incident response planning and breach handling.
Products using biometrics, AI, or large-scale analytics.
Henlin Gibson Henlin advises organisations on compliance and risk management across data privacy, regulatory issues, and disputes. If you need help classifying datasets, updating notices and contracts, or managing a privacy-related incident, a structured legal review can save significant cost and disruption later.