Above: Illustration created using Nano Banana.

Jeehan Miller, a Jamaican cybersecurity expert specialonising in data protection issues posted this article to her LinkedIn page on June 2, 2026. It is reproduced here with her permission.
In Trinidad and Tobago, there is no legal requirement for data breach disclosures and no requirement for the establishment in organisations of a data protection officer (DPO), but smart companies will recognise the need to exceed legal requirements in this matter and consider these guidelines.

When a cyber incident occurs inside an organisation, two teams spring into action, and they rarely speak the same language.

The IT department focuses on systems: what was compromised, how it happened, whether the perimeter is secure again.

The Data Protection team focuses on people: whose information was exposed, what rights have been affected, and what the law now requires.

These two perspectives are not opposites, they are two sides of the same coin, but the gap between them, if left unbridged, can expose an organisation to serious legal liability.

This article explores a scenario that is more common than organisations would care to admit: an IT team initially insisting that a security incident does not constitute a data breach, then later after careful questioning, conceding that it is a suspected breach, and even then resisting a full assessment of the scope of affected individuals.

It explores what the Jamaica Data Protection Act (2020) (“the DPA”) requires in such circumstances, and why having a professional who understands both IT and data protection is not a luxury, it is a necessity.

Phase One: “It was not a breach”

The first response from an IT team following a cyber incident is often defensive, and understandably so. I come from an IT background and admitting a breach can feel like admitting failure. The incident may involve a compromised workstation, unauthorised remote access, malware on a network endpoint, or a misconfigured server that briefly exposed data, but no evidence of data exfiltration. In IT terms, these events each have a technical name and a technical remedy. The firewall is patched. The malicious process is terminated. The affected machine is reimaged. In the IT team’s view: problem identified, problem solved. No breach.

But this is precisely where the translation problem begins.

What IT means vs. what the DPA means

When an IT professional says “there was no breach,” they typically mean one of the following:

• “We did not find evidence that data was exfiltrated” (i.e., copied and taken out)
• “The attacker did not get past our defences” (in their assessment)
• “We have now closed the vulnerability”
• “The affected machine has been isolated and remediated”

None of these statements, however accurate in a technical sense, means the same thing as “no data breach occurred” under the DPA.

Under the Jamaica Data Protection Act 2020, a data breach is not defined by whether data was definitively stolen. It is defined by whether there was a breach of security measures that affects or might affect personal data. The word “might” carries enormous legal weight. A security incident that creates a possibility of unauthorised access to personal data is sufficient to trigger the reporting obligation.

This is a critical distinction. The IT team is looking backward, at what they can prove happened. The DPA looks forward and outward, at what could have happened to the people whose data was held on those systems.

The danger of “Fully Resolved”: Why incident reports can mislead

One of the most problematic phrases that appears in IT incident reports is “fully resolved” — or its variants: “incident closed,” “threat neutralised,” “systems restored to normal operation.” To the business, and to legal and compliance teams reading those reports, this language implies that the matter is over.

It is not.

An incident can only be meaningfully described as fully resolved after a forensic investigation has been completed, one that examines what data was accessible, what the attacker actually did during the window of compromise, whether any data was copied or viewed, and critically, whether any persistence mechanisms were left behind.

In the absence of such an investigation, “fully resolved” means only that the visible symptoms have been addressed. Too often we hear that there was no data breach only to discover months later that there is data exposed on the dark web.

This distinction matters enormously under the DPA, and it matters for a very practical reason: threat actors do not always take what they came for on the first visit.

Threat actors are very patient, especially when it comes to high-value targets.

The hidden threat that IT Reports often miss: Backdoors and delayed consequences

One of the most dangerous misconceptions in incident response is the assumption that because a threat has been detected and removed, it has been fully eliminated. Sophisticated threat actors (and even some less sophisticated ones) routinely leave behind backdoors: hidden access points embedded in systems, often disguised as legitimate software, scheduled tasks, or dormant scripts, that allow them to re-enter the environment at a time of their choosing, long after the initial incident has been declared closed.

The sequence often looks like this:

• A threat actor gains access – through phishing, a vulnerability exploit, a compromised credential, or another method
• They spend time inside the environment – sometimes days, sometimes weeks, quietly mapping systems, escalating privileges, and identifying valuable data
• They may copy data before the intrusion is even detected
• When the IT team identifies the intrusion and remediates the affected systems, the threat actor may already be gone, or they may have left a backdoor that survives the remediation
• Weeks or months later, they return, or, they publish the copied data on the dark web, where it may be bought, sold, or freely distributed among criminal networks

This last point carries profound implications for data subjects. A person whose personal data was copied during an intrusion may face the consequences of that exposure not immediately, but months or even years later, through identity theft, targeted fraud, credential stuffing attacks on their other accounts, or being targeted by other criminal actors who purchased the data.

This is precisely why “the incident is closed” is not the same as “data subjects are not at risk.” The risk to an individual whose data was copied does not end when the affected machine is reimaged. It may be only beginning.

From a data protection perspective, the possibility that data was copied and could appear on the dark web, or that the threat actor retains access through a backdoor, must be factored into the organisation’s assessment of risk to data subjects, and into the notification decision.

If there is any reasonable possibility that personal data was accessed or copied, those individuals have a right to know.

Not every alert is a reportable breach: Understanding the threshold

It is important to acknowledge a practical reality that any organisation with a functioning security operations function knows well: security alerts are constant. Modern security tools — endpoint detection and response (EDR) platforms, security information and event management (SIEM) systems, intrusion detection systems (IDS), and firewalls, generate enormous volumes of alerts daily.

The vast majority of these are either false positives, low-severity events, or routine detections of known threats that are automatically blocked and require no further action.

Not every alert is a data breach.

Not every blocked intrusion attempt is a reportable incident.

Not every piece of detected malware that was quarantined before executing constitutes a breach of security measures affecting personal data.

The DPA’s reporting obligation is triggered by a breach of security measures that affects or might affect personal data – not by the mere existence of a cyber threat in the environment.

The distinction lies in whether personal data was or could have been compromised. A blocked port scan does not meet this threshold. A detected and quarantined phishing email that was never opened may not. A ransomware infection that encrypted systems containing personal data almost certainly does.

Understanding where an incident falls on this spectrum – whether it is a routine security event, a notable incident requiring internal investigation, or a reportable breach under the DPA – requires both technical knowledge and data protection expertise.

This assessment is part of what a qualified DPO with a cybersecurity background brings to the table.

The goal is not to report every alert to the Office of the Information Commissioner (OIC), which would be unworkable and would dilute the significance of genuine breach notifications. The goal is to apply the correct legal threshold with confidence and consistency, and to report promptly when that threshold is met.

Phase Two: Accepting “Suspected Breach”, and why that Is enough

With persistence, careful questioning, and the right translation of technical findings into data protection language, an IT team can usually be brought to a more candid position: “We cannot confirm data was accessed, but we cannot rule it out.” In other words, a suspected breach.

This concession matters enormously. A suspected breach is not a lesser category under the DPA that carries fewer obligations. It is the threshold at which mandatory reporting is triggered.

The DPA is clear: In Section 21(3)(b) a Data Controller who experiences a security breach in respect of the data controller’s operations which affects or may affect personal data,must report it to the Information Commissioner within 72 hours of becoming aware of the breach.

Critically, the Data Controller must not use this 72-hour window to first determine whether personal data was in fact affected, or to assess the full extent of the impact. Once the security breach has the potential to affect personal data, the obligation to report arises.

In plain terms: uncertainty is not a reason to delay reporting.

Uncertainty is itself the reason to report.

Reports can be updated in stages

A concern that organisations sometimes raise when the 72-hour deadline approaches is that they do not yet have all the facts. They are waiting on IT’s investigation. They have not confirmed the scope. They do not know exactly how many data subjects are affected. And so they hesitate to file a report that they fear will be incomplete or inaccurate.

This is a misunderstanding of how the reporting process works, and it can lead to a regulatory breach on top of the security breach.

The DPA’s reporting framework allows for staged or updated notifications to the Information Commissioner. An initial report can be filed with the information available at the time, clearly noting that the investigation is ongoing and that further details will follow.

As the investigation progresses and more becomes known , ie. the extent of the data affected, the number of data subjects involved, the likely cause and consequences of the breach, the report can be updated accordingly.

The principle is simple: report what you know, when you know it, and update as you learn more. Filing an initial report promptly, even if incomplete, demonstrates compliance and keeps the regulator informed. Waiting until everything is known before filing anything risks breaching the 72-hour obligation entirely , which is itself a violation of the DPA.

The 72-hour report to the Information Commissioner must include:

• The facts surrounding the security breach
• A description of the breach, including: The categories and estimated number of data subjects concerned The type and number of personal data records concerned
• The measures taken or proposed to mitigate or address the possible adverse effects
• The consequences of the breach
• The name, address and relevant contact details of the organisation’s Data Protection Officer

The DPO’s role at this stage is to ensure that the report is filed, not to wait until IT has completed its forensic investigation. And if that investigation is still underway, the report should say so.
Phase Three: The Scope Problem – Who Is Actually Affected?

Even after an organisation accepts that a suspected breach must be reported, a second and equally important battle often follows: determining the scope of affected data subjects.

One instinctive response from the business is to limit the scope to the users directly assigned to the compromised machines. If three workstations were affected, the thinking goes, then only the three employees who use those machines are data subjects of concern.

This instinct is understandable, but it is incomplete and potentially unlawful.

IT Scope vs. DPA scope: A critical distinction

In one recent case, the IT team asserted that a machine “belongs” to its assigned user. They were thinking in terms of accounts, login credentials, and user profiles only. But in data protection terms, a machine is a processing environment, a point through which data about many different individuals flows, is accessed, is stored, or is displayed. In this case, employee, vendor and client data could be accessed via the compromised machine.

Consider a typical workstation in a client-facing business environment. On any given day, that machine may have been used to:

• Open client records in a CRM or case management system
• Process customer transactions, including payment or identification data
• Access shared drives containing contracts, correspondence, or health information
• Display or print documents containing personal data of dozens or hundreds of individuals
• Connect to cloud-based systems where client data is stored

In such a scenario, the personal data potentially accessible via that machine does not belong only to the machine’s assigned user. It belongs to every client, customer, patient, or third party whose information could have been viewed, accessed, or extracted through that machine during the period of compromise.

The DPA’s obligation to notify affected data subjects is not limited to the employees of the organisation. It extends to all data subjects whose personal data was accessible through the compromised systems, which, in most real-world business environments, includes clients.

The Law on notifying data subjects

The DPA places a clear obligation on Data Controllers to promptly notify data subjects whose personal data is affected by a breach. This notification must include:

• The nature of the security breach
• The measures taken or proposed to mitigate or address potential adverse effects of the breach
• The name, address and contact details of the organisation’s Data Protection Officer

This notification must be written in clear and plain language, not in technical IT terminology, and not in legal jargon. It must be understandable to an ordinary person who has just been told that their personal information may have been compromised.

The discomfort of contacting a large number of clients is real.

It is an operational challenge

A reputational concern.

And sometimes a logistical nightmare.

But the DPA does not provide an exception for inconvenience.

The law requires it, and for good reason: affected individuals have the right to know that their personal information may be at risk so that they can take steps to protect themselves such as monitoring for identity theft, changing passwords, alerting their banks, or seeking other protective measures. They also have the right to be vigilant for the possibility that their data may surface on the dark web, and to take proactive steps to protect themselves if it does.

An often-overlooked step: Voluntary reporting to Jamaica CIRT

Beyond the mandatory obligations to the Office of the Information Commissioner , there is another reporting pathway that is frequently overlooked, and which represents an important act of good cyber-citizenship: voluntary reporting to the Jamaica Cyber Incident Response Team (JaCIRT).

Where a cyber incident has been confirmed such as malware infection, ransomware, unauthorised network access, or any other significant security event, organisations are encouraged to report it to Jamaica CIRT.

As part of this report, the organisation can share Indicators of Compromise (IoCs): the technical fingerprints of the attack, including malicious IP addresses, file hashes, domain names, email addresses, and attack signatures associated with the incident.

Sharing IoCs with Jamaica CIRT serves several important purposes. It contributes to a national picture of the cyber threat landscape, allowing the CIRT to identify patterns, track threat actors, and issue advisories that may protect other organisations from the same attack.

It also means that the reporting organisation is not carrying the burden alone. Jamaica CIRT may be in a position to assist with remediation, provide technical guidance on securing affected systems, and critically, support or facilitate forensic examination of the incident.

This forensic support is particularly valuable in cases where an organisation’s internal IT team lacks the specialised skills or tools to conduct a thorough investigation. A proper forensic examination can determine with far greater confidence whether data was accessed or exfiltrated, whether backdoors were implanted, and what the full scope of the incident was, information that directly feeds the DPA reporting obligations and the notification decision.

Reporting to Jamaica CIRT is not a legal obligation under the DPA.

But it is the responsible thing to do.

And it can meaningfully improve the quality of the organisation’s response to the incident.

The translator in the room: Bridging IT and data rotection

One of the most valuable but underappreciated roles in modern data governance is that of the professional who genuinely understands both sides. IT professionals are not data protection officers. Data protection officers are not typically system administrators. Each team has its own vocabulary, its own risk framework, and its own professional instincts.

I bring a specific combination of credentials to this space: a practising Data Protection Officer with a Cybersecurity certification, a Certified Ransomware Protection Officer, and an IT practitioner of over 20 years.

This combination means I can sit with an IT team, read their incident report, understand the technical detail, and then translate it – accurately and completely – into the language of data protection, regulatory obligation, and data subject rights. I can also sit with the Data Protection or Legal team and explain what the IT team actually means when they say “the endpoint was remediated” or “no lateral movement was detected.”

This is not a common combination.

Many DPOs come from legal, compliance, or HR backgrounds and must rely entirely on what IT tells them, without the technical foundation to ask the right follow-up questions.

Many IT professionals, conversely, have no training in data protection law and no professional obligation to think in terms of data subjects’ rights.

The gap between these two functions is real, it is common, and it has consequences. Breaches go unreported because IT says it is not a breach and no one in the room can push back with confidence. Notification scope is underestimated because no one maps the IT-defined incident boundary against the DPA’s data subject-centred framework. Incident reports use language like “fully resolved” that misleads decision-makers into thinking there is nothing left to do.

I can bridge that gap – and closing it protects the business, the data subjects, and the organisation’s standing with the regulator.

Translating IT speak into DPO speak

Here are some common examples of how the same incident is described differently, and what the DPO translation looks like:

IT Terms translated in plain language

“The machine was compromised by a remote access trojan (RAT)” means “An unauthorised party potentially had full visibility of and control over everything on that computer, including any personal data displayed, stored, or accessible from it”

“We found no evidence of data exfiltration” means “We cannot prove data was taken, but we also cannot prove it was not, so this is a suspected breach under the DPA”

“The endpoint was remediated” means “The computer has been cleaned and restored, but this does not undo any prior unauthorised access, and it does not confirm that no backdoor was left behind”

“Only the assigned users are affected” means “The affected individuals include all data subjects whose personal data was accessible through those machines. This may include clients, customers, or third parties”

“The incident is fully resolved” means “Visible symptoms have been addressed. Without forensic investigation, we cannot confirm what was accessed, whether data was copied, or whether persistence mechanisms remain”

“It was a phishing attack that was contained” means “An employee was deceived into granting access to their account or systems. We need to determine what personal data was accessible during the window of compromise”

“We’ve patched the vulnerability” means “The security gap has been closed. However, the gap existed for a period during which unauthorised access may have occurred”

“The logs don’t show any exfiltration” means “Logs record what was detected. They do not confirm that nothing occurred, some attack methods are specifically designed to avoid logging”

“We detected and blocked the threat” means “The attack was identified and stopped. However, there may have been a period before detection during which access occurred, the dwell time must be assessed”

“No lateral movement was observed” means “We did not detect the attacker moving to other systems. However, without forensics, this cannot be stated conclusively”

Translating a cyber-incident report for the data protection team

When IT produces an incident report, it is typically written for a technical audience. It will contain references to IP addresses, attack vectors, MITRE ATT&CK framework codes, endpoint detection and response (EDR) findings, and mean time to detect (MTTD) metrics. This report, as written, is of limited value to a Data Protection Officer trying to determine reportability, scope, and notification obligations.

A DPO with an IT background can take that incident report and produce a data protection translation that answers the questions the DPA actually asks:

• Was there a breach of security measures? → Yes / No / Suspected — and why
• Does it affect or potentially affect personal data? → What categories of data, held by whom, were accessible from the affected systems?
• Who are the data subjects? → Not just the machine’s assigned user, but all individuals whose data was in scope
• What is the risk to data subjects? → What could a bad actor do with the data that may have been accessed? Could it surface on the dark web?
• Are there residual risks? → Were backdoors potentially implanted? Has a forensic examination been completed?
• What is the organisation now doing? → Remediation steps in plain language, not technical shorthand

This translation is not about undermining IT. It is about ensuring that the organisation’s legal obligations are met in full, and that both teams are working from a shared understanding of what happened and what it means.
IT’s Job and the DPO’s Job: Different Mandates, Shared Purpose

It is important to acknowledge that IT and Data Protection are not in conflict – they simply have different primary responsibilities.

IT’s job is to protect the business – its systems, its networks, its operational continuity. When a breach occurs, IT’s instinct is to contain, remediate, and restore. These are essential functions. Without them, the organisation cannot operate.

The DPO’s job is to protect the data subject – the human being behind the data. When a breach occurs, the DPO’s obligation is to assess the impact on real people, fulfil the legal notification obligations, and ensure that individuals whose data may have been compromised are treated with the transparency and respect the DPA demands.

These mandates do not need to be in tension.

An organisation that contains a breach quickly and thoroughly, notifies the regulator within 72 hours, communicates clearly and promptly with affected data subjects, and engages Jamaica CIRT where appropriate, is protecting both its systems and its data subjects, and, in doing so, protecting its own reputation and legal standing.

The gap between IT and Data Protection is not inevitable. It is a product of different training, different vocabularies, and different risk frameworks. With the right bridge, a professional who speaks both languages fluently, and who holds both technical and data protection credentials , that gap can be closed.

What the Jamaica Data Protection Act requires: A summary

For clarity, the key obligations under the DPA in a breach scenario are as follows:

Reporting to the Information Commissioner (Section 19 of the DPA)

• Must occur within 72 hours of becoming aware of the breach (or potential breach)
• The 72-hour clock does not pause while IT completes its investigation
• A suspected breach, where it cannot be confirmed but cannot be ruled out, is sufficient to trigger the obligation
• Reports can be submitted in stages, file the initial report promptly, update it as further information becomes available from the ongoing investigation

Notifying affected data subjects

• Data Controllers must promptly notify data subjects whose personal data is affected
• Notification must be in clear and plain language
• It must describe the nature of the breach, the steps being taken, and the DPO’s contact details
• The obligation extends to all data subjects whose data was potentially accessible, not only employees or machine users
• Data subjects should be informed of any possibility that their data may be shared or published, including on the dark web, so they can take protective action

Organisational preparedness (Data Protection Standard 7)

Data Controllers must implement suitable technical and organisational measures to protect personal data
These measures must include clear procedures for breach identification, assessment, and notification
A documented breach response plan or checklist is strongly recommended
Procedures should distinguish between security alerts that do not meet the DPA reporting threshold and incidents that do

Good cyber-citizenship: Voluntary reporting to Jamaica CIRT

• Confirmed cyber incidents should be voluntarily reported to Jamaica CIRT
• Sharing Indicators of Compromise (IoCs) assists in national threat intelligence and protects other organisations
• Jamaica CIRT may be able to assist with remediation and forensic examination

Suspicion is sufficient. Notification is not optional. The investigation is never “done” until forensics says so.

When an IT team says “we don’t think it was a breach,” that is a technical assessment, not a legal one. Under the Jamaica Data Protection Act 2020, the legal threshold for mandatory reporting to the Information Commissioner is not proof of a data breach, it is the potential for one.

When an incident report says “fully resolved,” that is a statement about systems. It is not a statement about data subjects, about what was copied before remediation, about whether a backdoor survives on the network, or about whether stolen data is already sitting on a dark web marketplace waiting to be sold.

When an organisation resists notifying clients because the scope seems uncertain or the logistics seem burdensome, it is important to remind them: uncertainty about the scope does not reduce the obligation to notify. It increases the urgency of investigating and communicating promptly, and of seeking forensic assistance, whether internally or through Jamaica CIRT.

The Jamaica DPA exists to protect people, real people, whose names, financial details, health information, and personal circumstances are held by organisations that have a legal and ethical duty to safeguard them. When those safeguards are tested, the law requires transparency. Not eventually. Not after the IT team has completed a full forensic review. As soon as possible, with updates to follow as the picture becomes clearer.

The role of the DPO, particularly one who holds cybersecurity credentials, understands ransomware and advanced persistent threats, and brings over two decades of IT experience to the table, is to ensure that this transparency happens. To bridge the gap between the incident report and the legal obligation. To translate the language of systems into the language of rights.

That bridge does not undermine IT. It completes the picture, and it protects everyone.

If you are in need of a ‘translator’, contact me.

Jeehan Miller is a practising Data Protection Officer certified in Cybersecurity, a Certified Ransomware Protection Officer, and an IT practitioner of over 20 years. This article is intended for general guidance and awareness purposes.

Organisations facing a data breach or suspected breach should seek advice from their DPO promptly and appropriate legal advice from their legal team.She is an IT Consultant, Data Protection Officer, and Cyber Awareness Specialist. She is the Chief Privacy Officer for the Jamaica Artificial Intelligence Association and the Women in AI Governance Regional Chapter Chair for Jamaica.

She has over 20 years of experience in IT, holds an MBA in IT Management from the University of Leicester, a BSc in Computer Science from The University of the West Indies, a Certified Information Privacy Manager Certification from IAPP, and is ISC2 Certified in Cybersecurity.
Jeehan is also a Certified Ransomware Protection Officer and NIST Cybersecurity Expert from the ICTTF. She is passionate about educating vulnerable groups about cyber risks and online safety.