Does GDPR matter to Caribbean businesses, and why is it a CRM issue?
GDPR isn't Caribbean law, but it's the model nearly every new data protection law in the region is built on. It matters directly to CRM because a CRM is, functionally, the exact kind of system these laws regulate: a structured store of personal data collected from customers. Recent breaches at TSTT, Digicel, and Courts show that in territories where enforcement is weak or absent, the real accountability for mishandled data comes from customers and the market, not regulators, making data protection a trust and revenue issue for any business running a CRM, not just a legal one.
GDPR feels like a European problem until you start counting how many Caribbean companies have had customer data exposed in the last three years. Once you start counting, the "it doesn't apply to us" argument gets a lot harder to make.
I want to walk through what GDPR actually is, why it matters specifically for how we run CRM, where Caribbean data protection law currently stands, and three breaches that happened close to home: one in telecom, one in retail, one that reached all the way to the Prime Minister's own ID card. Then I want to connect it to something I think gets missed in most conversations about compliance: this isn't a legal issue sitting off to the side of the business. It's a CRM issue sitting at the centre of it.
What GDPR actually is
The General Data Protection Regulation is the EU's data privacy law, but its real significance outside Europe is that it became the template. Countries that never had a data protection law of their own (or had one nobody enforced) started building new legislation around GDPR's core ideas: consent has to be informed, people have a right to know what's held about them, and organisations are accountable for how they collect, store, and use personal information.
That's why you'll hear GDPR referenced constantly in the Caribbean even though it's not our law. It's the reference point everyone measures against, including the countries writing their own legislation right now.
Why this is a CRM problem, not just a legal one
Why is data protection a CRM strategy issue rather than just an IT or legal one?
Because a CRM is not just software that stores customer data: it's the output of decisions about people, process, technology, and data. Who can access sensitive fields, what a form actually asks for, and how long information is retained are all strategic and operational choices made before any data touches the platform. When a breach happens, the CRM makes the failure visible, but the failure itself almost always sits in the strategy and governance behind it, not the software.
Strip away the compliance language and a CRM is, functionally, the exact thing these laws regulate: a structured collection of personal data (names, contact details, financial information, sometimes ID numbers or health data) held by a business, about people who trusted that business enough to hand it over.
But it goes deeper than "the data lives in the CRM." At Engagent, we don't treat CRM as software: it's a strategy, built on people, process, technology, and data. Data protection isn't something that happens to a CRM after the fact. It's decided by the strategy behind it, long before anything ever gets stored:
- People: who's allowed to collect, view, or export sensitive data isn't a security setting. It's a role-design decision, made by a human, upstream of any software.
- Process: what a form actually asks for, why it's being asked for, and how long it's kept is a business process decision. HubSpot doesn't decide that. Your business does.
- Technology: this is where encryption, permissions, and request pages live. It matters, but it's the last mile, not the starting point.
- Data: the resulting governance of what's collected and why is the output of the first three, not a feature you switch on.
Sitting across all four of those is data governance: the specific discipline of who owns the data, what standard it has to meet, how long it's retained, and who's accountable when something goes wrong. Strategy explains why CRM isn't just software. Governance is how that strategy actually gets enforced day to day, and it's usually the layer that's missing when a breach happens, not the technology.
Every conversation about data protection is a conversation about your CRM, whether the person having it realises that or not. And every breach we're about to look at started the same way every CRM starts: someone filled out a form.
Where the Caribbean actually stands
Jamaica sets the standard the rest of the region should be measuring itself against. Its Data Protection Act, passed in 2020, is the most comprehensive framework in the Caribbean and closely mirrors GDPR: penalties of up to 4% of worldwide turnover, up to ten years imprisonment for individual violators, and an independent regulator (the Office of the Information Commissioner) with real power to investigate, issue enforcement notices, and prosecute. On paper, it's exactly what a modern data protection law should look like. In practice, even Jamaica's enforcement provisions weren't fully activated as of early 2026: the OIC has not yet taken formal action against a single data controller, though the government has said full activation is coming.
Trinidad and Tobago is further behind still. The Data Protection Act has existed since 2011, and remains only partially proclaimed, which in practical terms means large parts of it are not enforceable law. There's no independent regulator empowered to investigate or penalise. Legal commentary following our biggest local breach put it plainly: the country lacks the legal framework to hold companies accountable for protecting customer data at all.
That gap, a law on paper without an enforcement body behind it, is the single most important thing to understand about data protection in this region right now. It means the deterrent most businesses assume exists, doesn't. Which makes what happened at TSTT, Digicel, and Courts worth looking at closely, because in each case, the accountability came from the market and from customers directly, not from regulation.
Three breaches, three lessons
TSTT (Trinidad and Tobago, October 2023): This is the one that should have changed the conversation in this country permanently. RansomEXX, a ransomware group, exfiltrated roughly 6GB of customer data: names, emails, national ID numbers, ID scans, account details, and authorisation letters, eventually affecting well over 800,000 customers.
TSTT's early public statements downplayed the incident and were later contradicted by the leaked data itself. Worth noting through a governance lens: part of TSTT's own defence was that some of the exposed data came from an "outdated system that has been decommissioned from active use." That's not really a technical footnote; it's an admission that nobody owned the decision to archive or purge that data once it stopped being needed.
The fallout reached the top of the country: then-Prime Minister Keith Rowley confirmed his own ID and passport numbers were among the exposed data and called it a national security threat. TSTT's CEO departed the company shortly after. The regulator, TATT, said it was "disturbed"; but T&T had, and still has, no legal requirement forcing a company to disclose a breach within any timeframe at all.
-----------------------------------------------
Courts (Jamaica, 2023): A breach on the company's e-commerce platform, since discontinued. Payment and password data weren't exposed, and physical store customers weren't affected. What's notable is Courts' own response: they pointed directly to Jamaica's incoming Data Protection Act as the standard they were being held to, one of the few examples in the region of a company publicly tying its response to specific legislation, rather than treating the breach as a purely internal matter.
-----------------------------------------------
Digicel (Barbados, February 2026): A smaller-scale, very different kind of failure: human error, not an attack. A file containing customer names, addresses, emails, phone numbers, and account numbers was shared externally.
No passwords or financial data were involved, and Digicel notified affected customers directly. Where TSTT was a retention failure, this was an access-control one: a file that shouldn't have been shareable, got shared, which points to a gap in who owned the rules around what could leave the building and how. It's a useful counterpoint to TSTT: proof that you don't need a hacker for a data protection failure, and you don't need one for a governance failure either. A misdirected file does the same damage to trust.
What it means for the person filling out the form
This is where it stops being abstract. Think about what real estate, insurance, and financial services forms typically collect: ID numbers, income information, property details, sometimes health data for insurance underwriting. This is exactly the category of information that showed up in the TSTT leak: ID scans, authorisation letters, account data.
When that kind of information gets exposed, the risk isn't inconvenience. It's identity theft, targeted phishing built from real personal details, and (as cybersecurity commentary on the Digicel breach pointed out) enough raw material (name, address, phone number) to build a convincing profile of someone for impersonation or social engineering.
In a region where enforcement is inconsistent at best, the only real protection most consumers have is the discipline of the businesses collecting their data in the first place. That's not a comfortable position for a consumer to be in, and it shouldn't be a comfortable one for a business to leave them in either.
Why this is ultimately a trust and revenue conversation
Here's the connection I think gets missed most often: every one of these breaches was a customer relationship failure before it was anything else. TSTT didn't just lose data: it lost a CEO and a measure of public trust it's still working to rebuild. Courts had to publicly reassure customers and tie its response to legislation to be believed.
Trust is not a soft metric sitting next to revenue. It's upstream of it. A CRM's actual value isn't the software: it's the confidence customers have that what they hand over will be protected and used the way they were told it would be. Damage that confidence and you don't just have a compliance problem, you have a pipeline problem: renewals stall, referrals dry up, and every future form your business asks someone to fill out gets a little more resistance.
In a market where enforcement can't be counted on to protect anyone, how a business handles customer data becomes part of its actual value proposition, not a footnote to it.
How CRM applications like HubSpot supports better data stewardship
This is where the platform side is genuinely useful, independent of what local law does or doesn't require, and it's worth breaking into the two sides of the relationship it actually touches.
On the business side, HubSpot Enterprise includes a Sensitive Data feature built specifically for organisations handling the kind of information we've been talking about: financial records, health information, government IDs.
This isn't a generic field type; it's purpose-built for regulated data, with its own application-layer encryption, field-level permissions so only specific users or teams can see it, and audit logging that tracks every access. It's designed with HIPAA in mind (HubSpot will sign a Business Associate Agreement for it), which matters directly for our insurance clients, and the same protections apply to the ID numbers, income details, and property information real estate and financial services businesses collect every day.
If your organisation is capturing that category of data, this is the setting that determines whether it's sitting in a properly secured part of your CRM or just another contact property anyone with login access can open.
On the consumer side, HubSpot lets a business publish a data privacy request page: a page contacts can go to directly and ask to have their data deleted or exported, no email chain or phone call required. Those requests land in a Data Request Manager inside the CRM, where the business reviews, actions, and closes them out, with the deletion itself being permanent and irreversible once processed.
This is the practical answer to the "how would a consumer actually do this" question; it's not a workaround or a manual process someone has to build, it's a page that already exists inside the platform, waiting to be turned on.
None of this requires a regulator to mandate it. It's available now, and using it is a way of choosing a higher standard than the law currently forces on anyone in this region.
Key takeaways
- GDPR isn't Caribbean law, but it's the standard nearly every regional data protection law is now modelled on.
- A CRM is, by definition, the kind of system these laws regulate: this is a CRM conversation, not a side issue.
- Several Caribbean territories have data protection legislation with little or no enforcement mechanism behind it, a real gap, not a technicality.
- TSTT, Digicel, and Courts show three different failure modes: an attack met with poor disclosure, human error, and a contained breach handled with direct reference to law.
- Sensitive form data (ID numbers, financial and health information) carries real consequences when exposed, particularly in real estate and insurance contexts.
- Consumer trust and revenue are directly connected; data stewardship is a value proposition, not just a compliance line item.
- Tools like HubSpot's data request and consent features let a business set its own standard, regardless of what local enforcement currently requires.
COMMENTS