Data Protection and Data Privacy: Roles, Duties, Evidence
Many organisations use “data protection” and “data privacy” as if they mean the same thing. In practice, they overlap, but they are not identical. Getting the difference right matters because your roles, your duties, and the evidence you keep are what determine whether you can demonstrate compliance when a regulator, a customer, an auditor, or your board asks, “Show me how you protect personal data.”
This guide explains how data protection and data privacy work together under Jamaica’s Data Protection Act context, what each key role must do, and what “good evidence” looks like in day-to-day operations.
Data protection vs data privacy (what each term covers)
Think of data privacy as the rules and expectations around how personal data should be used. It focuses on fairness, transparency, purpose limitation, and people’s rights.
Think of data protection as the operational programme that makes privacy real. It covers governance, security, risk management, and controls that prevent misuse, loss, or unlawful processing.
They meet at accountability: if your organisation cannot evidence its decisions and controls, privacy becomes a statement, not a practice.
If you want a broader overview of the Act’s principles and individual rights, see PLMC’s guide on data privacy in Jamaica: key principles and rights.
Why “roles” matter (accountability is assigned, not assumed)
Most compliance failures are not caused by a missing policy. They happen because:
No one is clearly accountable for approvals and decisions.
Teams handle personal data every day, but do not know their obligations.
Controls exist “in IT,” while privacy duties sit “in Legal,” and neither side can produce end-to-end evidence.
Regulators and auditors typically expect accountability to be built into your operating model, a concept also strongly emphasised by the UK Information Commissioner’s Office in its guidance on the accountability principle.
Core roles in a privacy and data protection programme
Titles vary, but the responsibilities should be clear and documented.
Board and senior management
Primary duty: Set expectations, fund controls, and require reporting that focuses on risk and evidence, not just policies.
What this looks like in practice: approving privacy risk appetite, endorsing key policies, and asking for proof that controls are working (for example, training completion trends, incident metrics, vendor risk status).
Data Controller (the organisation deciding why and how data is used)
Primary duty: Ensure processing is lawful, fair, transparent, and secure, including when third parties process data on the controller’s behalf.
Common controller tasks: privacy notices, lawful basis decisions, retention decisions, handling rights requests, vendor oversight, breach governance.
Data Processor (a service provider processing for the controller)
Primary duty: Process only on documented instructions, keep data secure, support the controller with rights requests and incidents, and demonstrate compliance with contractual requirements.
Processors often fail on evidence, not intent. “We have security” is not enough. A controller may ask for proof such as policies, penetration testing summaries, access control records, or breach notification procedures.
Data Protection Officer (DPO) or privacy lead (where appointed)
Primary duty: Drive the programme, advise on risk, monitor compliance, coordinate evidence, and keep the organisation honest.
Even where a formal DPO is not legally required for every organisation, assigning a capable privacy lead is a practical necessity. Someone must own the compliance calendar, evidence pack, and reporting.
Information Security (IT and security functions)
Primary duty: Implement and operate security controls that support privacy obligations, such as access control, encryption, logging, vulnerability management, backups, and incident response.
A useful way to align expectations is to map privacy risks to security controls using well-known frameworks (for example, the NIST Cybersecurity Framework).
Legal and compliance
Primary duty: Translate legal obligations into internal rules, contracts, and defensible decisions.
This includes vendor clauses, cross-border data transfer considerations, complaint handling, and ensuring marketing, HR, and customer operations use the correct notices and consent mechanisms where relevant.
HR, customer service, marketing, and business unit owners
Primary duty: Apply privacy requirements where personal data is actually collected and used.
Most privacy incidents happen at the operational edge: sending an email to the wrong recipient, oversharing in a WhatsApp group, using a shared password, or collecting “just in case” data.
Duties that typically apply across the organisation
Your exact obligations depend on your processing, but most organisations should be able to evidence the following:
1) Know what data you have and where it goes
If you cannot describe your personal data flows, you cannot control them.
Evidence is not just a spreadsheet. It is also proof the inventory is maintained and used (for example, updated when new systems go live).
2) Be clear on purpose and lawful basis
Each key processing activity should have a defined purpose and justification. This is also where many organisations struggle to stay consistent between:
what the privacy notice says,
what staff believe they are allowed to do,
what systems and vendors actually enable.
3) Provide privacy notices that match reality
Notices should be understandable, accessible, and consistent with actual processing. They must not be “legal text that no one follows.”
4) Handle individuals’ rights consistently
Rights requests are not rare anymore, especially where customers are more privacy-aware. The risk is not only missing a deadline, it is giving an incomplete response because data is fragmented across systems and vendors.
5) Secure data end-to-end
Security must cover people, process, and technology. A strong privacy programme can rarely outperform weak security.
6) Control vendors and outsourced processing
If a vendor mishandles data, your organisation still carries significant accountability as controller. Vendor risk must be assessed before onboarding, and monitored afterward.
7) Be breach-ready
The test is not whether you have an incident response plan. The test is whether you have rehearsed it, and whether logs, roles, and escalation paths work during stress.
The evidence pack: what “proving compliance” looks like
A practical rule: If it is not documented, versioned, and repeatable, you will struggle to prove it. Evidence should show both design (the rule) and operation (the rule is followed).
Evidence by role (who should be able to produce what)
Role | Typical responsibilities | Evidence you should expect to see |
Board / CEO | Oversight, resourcing, risk acceptance | Board minutes referencing privacy risk, approved policies, budget approval, KPI/KRI reporting |
Privacy lead / DPO | Programme management, advisory, monitoring | Training plan and completion stats, DPIA or risk assessment register (where applicable), RoPA or data inventory, audit findings log |
Legal / Compliance | Contracts, notices, governance | Privacy notices, vendor contract clauses, retention policy, complaint handling procedure |
IT / Security | Control operation, monitoring, response | Access control reviews, security logging, patching records, vulnerability scans, incident tickets, backup and recovery test results |
HR / Business units | Collection and use aligned to policy | Data collection forms, scripts, call recordings guidance, SOPs, staff acknowledgements, evidence of secure disposal |
Vendors (processors) | Processing under instruction, security | Processor security attestations, breach notification process, subprocessor list, audit reports or summaries (where provided) |
Evidence by duty (simple mapping you can use internally)
Duty | Minimum “credible evidence” | How often it should be updated |
Data inventory and flows | Record of processing activities (or equivalent), system list, data flow notes | Quarterly, and when systems change |
Lawful basis and purpose | Documented basis per major activity, approval trail | When launching or changing processing |
Transparency | Privacy notice versions, publication date, review notes | At least annually |
Rights handling | Workflow, templates, request log, response QA checks | Ongoing, reviewed quarterly |
Security controls | Access review logs, change management records, security monitoring evidence | Monthly to quarterly depending on control |
Vendor management | Due diligence checklist, risk ratings, signed agreements, review schedule | At onboarding and at renewal |
Retention and disposal | Retention schedule, deletion logs, disposal certificates | Ongoing, reviewed annually |
Incident readiness | Incident response plan, tabletop exercise notes, lessons learned actions | At least annually |
Training and awareness | Completion records, role-based modules, attendance sheets | Quarterly tracking, annual refresh |
PLMC also shares a more operational checklist you can use to sanity-check your programme in privacy and data protection: a practical checklist.
Common evidence gaps (and how to fix them quickly)
“We have a policy” but no proof it is used
Fix: keep an evidence trail that demonstrates use, for example sign-offs, workflow tickets, audit logs, and periodic control testing results.
The data inventory exists but is outdated
Fix: tie the inventory to change management. If a new app is procured or a form changes, the data map must be updated before go-live.
Rights requests are handled ad hoc
Fix: implement a single intake route (email address or portal), a request log, standard response templates, and a clear internal SLA for each data source owner.
Vendors are “trusted” but not assessed
Fix: use a vendor due diligence checklist, require written security and privacy commitments, and schedule reviews based on risk.
Security is strong but not connected to privacy
Fix: map security controls to privacy risks. For example, access control reviews and logging are not only IT hygiene, they are privacy evidence.
A short self-test: can you demonstrate compliance this week?
If a regulator, a bank partner, or a major customer asked for proof within five business days, could you produce:
a current data inventory and vendor list,
your privacy notice and last review notes,
a rights request log (even if it is “none received”),
evidence of access reviews and staff training completion,
an incident response plan plus at least one test or exercise record?
If the answer is “some of it,” you are not alone. The quickest path forward is usually to define owners for each evidence set, agree a review cadence, and build a single evidence pack that is easy to export.
Frequently Asked Questions
What is the difference between data protection and data privacy? Data privacy focuses on lawful and fair use of personal data (transparency, purpose limitation, rights). Data protection is the operational programme of governance and security controls that makes privacy enforceable and demonstrable.
Who is responsible for compliance, the controller or the processor? Both have responsibilities, but the controller typically carries primary accountability for lawful processing and vendor oversight. Processors must follow documented instructions, keep data secure, and support the controller with rights requests and incidents.
What evidence should a Jamaican organisation keep to show compliance? Common evidence includes a data inventory (records of processing), privacy notices and review history, rights request logs, vendor due diligence and contracts, security control records (access reviews, logging), retention schedules, training records, and incident response tests.
Do we need a Data Protection Officer (DPO)? It depends on your processing and risk profile. Even where a formal DPO is not required, appointing a clear privacy lead is a practical requirement so roles, decisions, and evidence do not fall between departments.
How often should we review our privacy programme evidence? High-impact items (access reviews, vendor status, incidents, rights handling) should be monitored at least quarterly. Policies and notices should typically be reviewed annually, and whenever processing changes.
Need help assigning roles and building an evidence pack?
PLMC supports organisations in Jamaica with data protection implementation, privacy training, and practical compliance evidence that stands up to scrutiny. If you want an objective view of your current roles, duties, and gaps, you can request a consultation via Privacy & Legal Management Consultants Ltd. or start by reviewing PLMC’s Data Protection Act guide for businesses.