PII Handling Basics

What counts as personal information

Personal information — often called PII — is any data that identifies an individual or could, combined with other data, do so. Obvious examples are names, contact details, and identifiers; less obvious ones include device identifiers and pieces that are harmless alone but identifying together. In a debt-recovery context, much of the data handled relates to identifiable people, so the bar for care is high.

Treat the definition broadly. If a field might identify someone, handle it as personal information rather than splitting hairs. The cost of over-protecting a field is small; the cost of mishandling genuine personal data — to the individual and to trust in your service — is large.

Collect little, use narrowly

Two principles do most of the work. Data minimisation says collect only what you actually need for the task at hand — not everything that might one day be useful. Purpose limitation says use the data only for the reason it was collected, not for unrelated new purposes bolted on later.

Together they shrink your risk and your obligations. Every extra field you collect is something you must then secure, justify, and eventually dispose of. Before adding a personal data field to a request or a record, ask what specific purpose requires it; if there is no clear answer, leave it out.

Protect the whole lifecycle

Personal data needs protection at every stage. In transit, use the transport encryption covered in securing data in transit. At rest, encrypt and control access. In use, restrict who and what can read it. And at the end, dispose of it deliberately when it is no longer needed rather than letting it accumulate indefinitely.

Access should follow least privilege: each person and service sees only the personal data its role genuinely requires. Broad, unaudited access to personal information is a standing risk, because the more places data can be read, the more ways it can leak.

Mind the accidental leaks

Personal data most often escapes not through dramatic breaches but through carelessness: a full record dumped into a log, an email address echoed in an error message, or sensitive fields included in analytics events. These leaks are easy to create and easy to overlook because the code still works.

# leaks personal data into the log stream
log.info('processing ' + customer.full_record)
# safer: reference, do not reproduce
log.info('processing', customer_ref=customer.id)

Redact personal fields before logging, keep them out of error responses, and review what your telemetry actually captures. Build the safeguard into shared helpers — a logger that strips known sensitive keys, an error formatter that returns a reference rather than the offending value — so safety does not depend on every developer remembering at every call site. The leaks that matter are rarely deliberate; they are the ones a tired engineer adds without thinking, which is exactly why the protection belongs in the plumbing.