Data Protection Procedures: From Collection to Deletion

Most organisations can point to a privacy policy. Fewer can show the day-to-day data protection procedures that make that policy real, across every team, system, and spreadsheet.

In Jamaica, where the Data Protection Act has pushed privacy from “good practice” into a board-level compliance topic, procedures are the difference between:

• A privacy programme you can evidence during an audit, investigation, vendor review, or incident.

• A set of documents that look good until something goes wrong.

This guide walks through practical, end-to-end procedures across the data lifecycle, from collection to deletion, with a focus on what Jamaican organisations need to do, document, and prove.

Start with the lifecycle (so procedures match reality)

Data rarely sits in one place. It moves from web forms to email inboxes, from HR folders to payroll systems, from call recordings to customer support platforms, and into vendor environments. Good procedures follow that movement.

A simple way to structure your operating model is to define procedures for each lifecycle stage and assign clear ownership.

Procedure 1: Collection, get it right at the door

Collection is where many compliance issues begin, especially with online forms, onboarding packs, CCTV, and ad hoc “send me your ID” email requests.

1) Define the purpose before you build the form

Your collection procedure should require a short purpose statement that answers:

• Why are we collecting this data?

• Which business process uses it?

• Who will access it?

• How long will we keep it?

This prevents scope creep later (for example, using onboarding documents for unrelated analytics).

2) Minimise fields and set “must have” rules

Operationally, minimisation means you do not ask for fields unless someone can justify them.

Common high-risk collection points in Jamaica include:

• Job application forms and CV intake (IDs, TRN, references)

• Customer onboarding and KYC (IDs, proof of address)

• Schools and youth programmes (children’s data)

• Health-related information for workplace fitness, sick leave, or insurance administration

A strong procedure includes a review gate: if a team wants to add a new data field, they submit a change request and get approval from the appropriate privacy or compliance owner.

3) Standardise your notice wording

Your privacy notice does not need to be “legalese”, but it must be consistent. A collection procedure should point staff to approved notice templates for:

• Websites and apps

• Paper forms

• Call centre scripts

• CCTV signage

If different departments write their own mini-notices, transparency becomes inconsistent and difficult to defend.

4) Treat consent as a controlled tool, not a default

Many organisations overuse consent when another lawful basis would be more appropriate for routine operations. Your procedure should spell out when consent is permitted, who approves it, and how withdrawal is handled.

If you do use consent, build it like a system:

• Record what the person was told at the time

• Record the choice and timestamp

• Make withdrawal as easy as opt-in

Procedure 2: Internal use, control access and prevent “function creep”

Once data is collected, the biggest risk is usually internal: too many people can see too much, for too long.

Access control procedure (minimum standard)

A practical access procedure is often the fastest risk reducer because it is measurable.

Include these elements:

• Role-based access: access granted by job role, not by individual preference.

• Joiner, mover, leaver steps: access granted at onboarding, reviewed on role change, removed immediately on exit.

• Periodic access reviews: managers re-certify access for their teams.

• Logging and monitoring: key systems retain access logs for investigation and accountability.

If you are aligning with recognised frameworks, the NIST Privacy Framework can help structure privacy controls alongside security and risk management.

Staff procedure for “reasonable use” of personal data

Even with good system controls, staff behaviour matters. Your internal use procedure should be backed by training and simple rules that reduce everyday exposure:

• Do not export customer lists unless there is an approved business need.

• Do not move personal data into WhatsApp groups for convenience.

• Do not store IDs, TRNs, or health data in personal inboxes.

• Use approved collaboration tools with controlled access.

Procedure 3: Sharing and vendors, make disclosure defensible

Third-party processing is one of the hardest areas to evidence because the risk lives outside your walls.

A share-and-disclose procedure should cover both:

• Controller-to-controller sharing (you disclose to another organisation).

• Controller-to-processor arrangements (a vendor processes on your instructions).

Build a “no contract, no data” rule

A practical standard is: no personal data is shared with a vendor until minimum contractual and due diligence requirements are met.

If you operate across borders or use cloud services, build a transfer checkpoint into the procedure: document where data is stored, who can access it, and what safeguards apply.

For organisations building a broader governance approach, PLMC’s resources on compliance planning can complement this, for example the Data Protection Jamaica: Compliance Roadmap for 2026.

Procedure 4: Storage and security, make protection repeatable

Security controls fail when they depend on individual heroics. Procedures convert security into repeatable operations.

Create a simple classification and handling rule

You do not need an overly complex scheme. Many organisations do well with three tiers:

• Public

• Internal

• Confidential (personal data and sensitive information)

Then map each tier to handling requirements such as encryption, sharing methods, and approval gates.

Minimum security procedure elements (privacy-relevant)

Your storage and security procedure should at least define:

• Device security (screen locks, encryption, lost device reporting)

• MFA requirements for remote access and admin accounts

• Patch management and vulnerability handling

• Backup standards and restoration testing

• Physical security for paper files and office storage

• Secure configuration for email forwarding and shared mailboxes

If you want a privacy-focused extension to an ISO security programme, ISO/IEC 27701 is widely used as a privacy information management standard layered on ISO/IEC 27001.

Procedure 5: Rights requests, build a workflow you can run under pressure

Individuals’ rights are where many organisations struggle because the work cuts across systems, teams, and vendors.

A good rights-handling procedure should be designed so it still works when:

• The request arrives through an unusual channel (social media message, call centre, branch office).

• The request is unclear or overly broad.

• The data is spread across multiple systems and vendors.

Rights handling workflow (operational version)

Define a consistent internal flow:

• Intake and logging: capture the request, channel, date, and case owner.

• Identity verification: confirm the requester is the data subject (or authorised agent).

• Scoping: identify systems, departments, and vendors that may hold the data.

• Search and collection: retrieve records in a controlled way.

• Review and decision: apply any legal limits or exemptions, document reasoning.

• Response: provide the response securely and consistently.

• Close-out: record what was provided, when, and any follow-up actions.

The core principle is consistency and auditability. You want to be able to show that two similar requests were handled in the same way, regardless of who received them.

If you need a broader baseline of privacy obligations and terminology for staff, PLMC’s guide Jamaica Data Protection Act Explained for Businesses can support internal awareness.

Procedure 6: Retention and deletion, turn “storage limitation” into a schedule

Most organisations do not intentionally hoard data. It happens because nobody owns retention decisions and deletion is inconvenient.

A defensible retention and deletion programme needs two linked components:

• A retention schedule (what to keep, why, and for how long)

• A deletion and disposal procedure (how data is actually removed)

Retention schedule procedure

Retention must reflect real drivers, including:

• Legal and regulatory requirements

• Contractual requirements

• Limitation periods and dispute risk

• Operational needs (for example, warranty claims)

Instead of arguing about exact time periods in a vacuum, structure the discussion around record categories and triggers.

Your retention procedure should also include a legal hold step: when litigation, investigation, or regulatory review is reasonably expected, deletion pauses for relevant records, with approvals documented.

Deletion and disposal procedure (what “done” looks like)

Deletion is not one action. It differs by system type.

Your procedure should define how you handle:

• Business systems: delete or anonymise records, capture a deletion ticket or log.

• Shared drives: enforce retention folders, periodic clean-ups, access restrictions.

• Email: mailbox retention rules, limits on forwarding, controlled archiving.

• Backups: define what you do and do not delete from backups, and how long backups are kept.

• Paper records: shredding, secure bins, disposal certificates from service providers.

A practical deletion procedure also includes an exceptions register. If data cannot be deleted immediately (for example, due to system limitations), document the reason, compensating controls, and the plan to fix it.

Procedure 7: Breaches and incidents, prepare for the worst day

Incidents are not only hacking. They include misdirected emails, lost laptops, unauthorised database access, and public disclosures.

A breach procedure should be tested, not just written. At minimum, it should define:

• What counts as a privacy incident (with examples relevant to your operations)

• Who staff must notify immediately

• Triage steps (containment, recovery, evidence preservation)

• Risk assessment steps (what data, how many people, likely harm)

• Notification decision-making and approvals (including regulator and affected individuals where required)

• Post-incident corrective actions and training

This is also where privacy and cyber security must meet. If you handle both through a single response playbook, you move faster and document better.

Assign ownership, otherwise procedures do not operate

Procedures fail most often because accountability is unclear. Even small organisations can assign clear roles, even if one person wears multiple hats.

A lightweight RACI model helps teams act without delay.

(As a reminder: Responsible does the work, Accountable owns the outcome, Consulted provides input.)

Measure what matters, so you can prove improvement

If you want your procedures to hold up under scrutiny, pick a small set of metrics that show control maturity over time.

Examples that are practical in 2026:

• Percentage of systems and key spreadsheets included in the data inventory

• Percentage of vendors with completed due diligence and signed data protection clauses

• Time to close rights requests (tracked against your internal target and legal requirements)

• Access review completion rate for high-risk systems

• Percentage of staff completing privacy training by role

• Number of overdue deletion actions and documented exceptions

Metrics are also useful for boards and senior leadership because they translate “privacy risk” into operational visibility.

Put it into action with templates and a realistic rollout

If you already have high-level compliance guidance, convert it into a procedure pack that teams can actually use:

• Collection and notice procedure (with approved templates)

• Access control and internal use procedure

• Vendor and sharing procedure

• Rights request workflow

• Retention schedule and deletion procedure

• Incident response procedure (privacy integrated)

For a practical baseline you can align to, PLMC’s Privacy and Data Protection: A Practical Checklist is a useful companion, then this article helps you turn that checklist into operational steps.

Need help building data protection procedures that stand up to scrutiny?

PLMC supports Jamaican organisations with data protection implementation, GRC integration, risk assessment tools, and training that turns requirements into repeatable operations. If you want to map your data lifecycle and build procedures from collection to deletion, you can start with a free consultation via Privacy & Legal Management Consultants Ltd..