
Data Protection and Privacy Policy: One Doc or Two?

Most organisations in Jamaica know they need “a privacy policy” once the Data Protection Act (DPA) enters the conversation. The confusion starts when someone asks a very practical question: do we need a data protection policy and a privacy policy, or can one document cover both?
The right answer depends on your audience, your risk profile, and what you want the document to achieve. In many cases, “one doc” is possible, but “two docs” is cleaner, safer, and easier to operate.
Quick definitions (so everyone is talking about the same thing)
In day-to-day compliance work, these terms are often used interchangeably, but they serve different jobs.
Privacy policy (often really a “privacy notice”)
A privacy policy is typically an outward-facing document that explains how your organisation handles personal data. It is written for:
Customers and clients
Website visitors
Employees (sometimes via a separate employee notice)
Members of the public
Its purpose is transparency: what you collect, why, how you use it, who you share it with, and how people can exercise their rights.
Data protection policy (internal policy)
A data protection policy is an inward-facing governance document that sets the rules your organisation follows to comply with the DPA. It is written for:
Staff
Management
Contractors handling personal data
Process owners (HR, IT, Operations, Marketing)
Its purpose is control and accountability: who does what, what is allowed, what is prohibited, and what procedures must be followed.

Why the “one doc or two” decision matters under Jamaica’s Data Protection Act
A privacy policy that reads well but does not match your actual operations creates risk. An internal data protection policy that is never trained, followed, or enforced also creates risk.
The DPA is not only about having paperwork. It is about demonstrating that you process personal data lawfully, fairly, transparently, and securely, and that you can evidence those decisions.
In practice:
External transparency is primarily delivered through privacy notices/policies.
Internal accountability is delivered through policies, procedures, training, risk assessments, and governance.
You can combine transparency and accountability into one document, but you must still satisfy both needs.
One document can work (when done carefully)
For smaller organisations, a single consolidated document can be workable if it is structured properly.
A “single doc” approach is more realistic when:
You have a relatively simple service offering and limited personal data processing.
You have one main audience (for example, a small professional services firm with one website and one client onboarding process).
Your internal team is small, and the same people who make decisions also handle the data.
You can maintain the document (updates, version control, approvals) without it becoming a burden.
If you choose one doc, structure it like two
A common pitfall is writing one document that tries to do everything, then ends up doing neither well. If you combine, separate sections clearly:
Section A: Public-facing privacy information (written in plain language)
Section B: Internal rules, roles, and procedures (written for staff)
Also consider whether the internal section should be distributed separately to staff even if it lives in the same master document.
Two documents are usually better (and more defensible)
For many organisations, separating the documents reduces operational and legal risk.
A “two doc” approach is strongly recommended when:
You process special categories of data (for example, health-related information) or other sensitive datasets.
You handle high volumes of personal data (retail, telecoms, finance, education, healthcare, large employers).
You have multiple processing contexts (marketing, CCTV, HR, customer apps, vendor platforms).
You use multiple processors and third parties (payroll providers, cloud services, CRM tools, call centres).
You need role-based rules (HR does one thing, Marketing does another, IT has separate security obligations).
You want a clean separation between what the public sees and what your internal team must follow.
Decision guide (simple and practical)
Question | If your answer is “Yes” | What it suggests |
Do you have multiple departments processing personal data differently (HR, IT, Marketing, Operations)? | Complexity is higher | Two documents are usually better |
Do you need staff to follow specific steps (rights requests, retention, breach escalation, vendor onboarding)? | You need operational control | You need an internal data protection policy (even if short) |
Are you publishing something on your website or giving it to customers? | You need public transparency | You need a privacy policy/notice that is readable and clear |
Would sharing your internal procedures publicly create security or operational risks? | Keep internal details private | Separate docs are safer |
Are you trying to “tick the box” with a template? | High mismatch risk | Separate docs help force clarity and ownership |
What goes in a privacy policy (external) versus a data protection policy (internal)
Think of it this way: the privacy policy explains, the data protection policy governs.
Typical content of an external privacy policy
Your privacy policy should be understandable to non-lawyers. It should describe what actually happens, not what you wish happened.
Common sections include:
Who you are (the organisation responsible for the processing)
What personal data you collect (categories)
Why you collect it (purposes)
The legal basis/authority for processing (where applicable)
Who you share it with (categories of recipients)
Cross-border transfers (if you use overseas cloud services or vendors)
How long you keep it (retention approach, even if you reference a separate schedule)
Security (high-level, avoid giving attackers a roadmap)
Individual rights and how to make a request
How to contact you (and the relevant internal role or contact point)
Updates and versioning
Typical content of an internal data protection policy
Your internal policy should tell staff what they must do and what they must not do, and it should connect to procedures.
Common sections include:
Roles and responsibilities (management, HR, IT, data owners, vendors)
Data protection principles the organisation follows
Rules for collection and use (data minimisation, purpose limitation)
Access controls and “need-to-know” handling
Retention and disposal expectations (linked to a retention schedule)
How to handle rights requests internally (routing, timelines, verification)
Vendor and processor onboarding rules (contracts, due diligence)
Incident and breach reporting (who to notify internally and how quickly)
Training expectations and policy enforcement
Monitoring, audits, and review cycle
Side-by-side comparison table
Element | Privacy Policy (External) | Data Protection Policy (Internal) |
Primary audience | Customers, website visitors, employees (as data subjects) | Staff, management, contractors |
Main goal | Transparency and trust | Governance and compliance control |
Tone | Plain language, user-friendly | Operational and directive |
Includes procedures? | Usually no (or only high-level) | Yes, or links to procedures |
Published publicly? | Often yes | Generally no |
Evidence for compliance | Shows what you tell people | Shows what you actually require staff to do |
Common mistakes organisations make (and how to avoid them)
Mistake 1: Treating a privacy policy as a marketing footer
A privacy policy is not just a website requirement. If your organisation collects personal data in onboarding, HR, CCTV, call recordings, WhatsApp conversations, or events registration, your privacy messaging must cover those realities.
Better approach: map the main ways you collect personal data, then make sure your privacy policy reflects those scenarios.
Mistake 2: Publishing internal details that should not be public
Sometimes organisations publish operational security details in the name of transparency.
Better approach: keep security disclosures high-level (for example, “we use technical and organisational measures”) and document the specifics internally.
Mistake 3: Copying a template that does not match your organisation
Templates can help with structure, but they often include irrelevant statements (or miss critical activities).
Better approach: validate every section against your real data flows: what systems you use, what vendors you rely on, and what your staff actually do.
Mistake 4: Having documents that no one owns
Policies fail when there is no clear owner, no approval pathway, and no review schedule.
Better approach: assign responsibility (even if it is a small team), set review dates, and record approvals.
A practical way to choose (and implement) your approach
If you are deciding right now, use this practical standard:
If you need the public to read it, write a privacy policy that is clear, accurate, and specific.
If you need staff to follow it, write a data protection policy that is operational, trainable, and enforceable.
Many Jamaican organisations end up with two documents, plus supporting documents such as:
A retention schedule
A breach/incident response procedure
A vendor due diligence and contracting process
Role-based training materials
You do not need to create everything at once, but you should plan for an ecosystem where documents support each other.

Frequently Asked Questions
Is a privacy policy the same as a privacy notice? In many organisations, “privacy policy” is used to mean “privacy notice.” The key is function: it should explain to individuals how you collect, use, share, retain, and protect their personal data, and how they can exercise their rights.
Do we need a separate employee privacy notice in Jamaica? Often, yes. Employee data processing is usually more complex than website visitor data (payroll, benefits, performance, monitoring, medical information). You can include employees in one notice, but many organisations choose a separate employee-facing notice for clarity.
Can we combine our website privacy policy and internal data protection policy into one document? You can, but it is rarely ideal. If you combine, clearly separate public-facing content from internal rules and procedures, and control distribution so internal operational details are not publicly posted.
What is the biggest risk of using one document for everything? The document becomes too vague to guide staff and too complex for customers to understand. That increases the chance of a mismatch between what you say and what you do.
How often should these documents be reviewed? At minimum, review when your processing changes (new system, new vendor, new customer journey), after incidents, and on a scheduled cycle (many organisations choose at least annual review). The right frequency depends on how fast your operations change.
Does having the documents mean we are compliant with the Data Protection Act? Documents are only part of compliance. You also need evidence that the organisation follows them (training records, vendor contracts, access control, retention and disposal actions, incident logs, and rights-request handling).
Need help deciding what your organisation should publish, and what it should operationalise?
Privacy & Legal Management Consultants Ltd. (PLMC) helps Jamaican organisations build practical, defensible data protection compliance, including privacy documentation, implementation support, and training.
If you are unsure whether to use one document or two, or you want your current policy reviewed against your real processes, visit Privacy & Legal Management Consultants Ltd. to request a consultation and align your documentation with how your organisation actually handles personal data.
