Personal data privacy guide: collection, use, sharing, retention, security, deletion, and accountability

What to take away

Privacy is a lifecycle, not a setting. A strong password cannot make unnecessary collection fair.
Write the purpose before the field list, and let the purpose decide what may be kept.
Follow data through apps, vendors, logs, backups, exports and test copies, not just the live database.
Access, correction, portability, objection and deletion are five separate actions with separate clocks.
Security protects data. Privacy also asks whether the processing should happen at all.

Personal data privacy is how information connected to a person is collected, used, shared, kept, protected and finally retired. A password keeps an intruder out. It says nothing about whether the record should exist.

Start with the person and the purpose

Describe the outcome before listing fields. A courier needs an address to finish a delivery. That does not justify keeping precise location history, importing contacts, or reusing the address for an unrelated profile.

Write the purpose down in one testable sentence. "Improve services" fails the test. It cannot tell you which field is necessary, who may receive it, or when it should disappear.

Then name the boundaries:

who is affected;
the service or decision involved;
the fields needed for it;
where each field comes from;
who may use it;
the event that ends the need.

Map where the data actually goes

Collection is the first stop, not the whole trip. Data is typed by a person, observed by a sensor, received from another company, generated by a transaction, or inferred from behavior.

It then moves.

Data movement across eight hops

Browser
Identity provider
Analytics service
Support desk
Payment processor
Warehouse
Backup
Export

For every hop, record these details:

source
destination
field
purpose
access
protection
retention rule
deletion route Include the copies people forgetlogs, support attachments, test environments, cached files and contractor workspaces.

The NIST Privacy Framework getting-started material organizes this work around Identify-P, Govern-P, Control-P, Communicate-P and Protect-P. It also states that the Core is not a universal checklist. Use it as a risk map, not as proof of compliance.

Tell the kinds of data apart

A direct identifier names a person: a name, an account number, an email address. An indirect identifier points to someone only when combined with other records.

Sensitive information covers health, financial, precise location, identity and communications. Its legal definition changes by province and by statute, so check the rule that applies to you rather than assuming one list.

Metadata describes an event. It includes time, sender, recipient, and device. It also includes location and file properties. Inferred data is a conclusion drawn from other signals. Pseudonymous data still has a route back to a person while additional information exists. Stripping names alone rarely settles whether data is anonymous.

Control collection and reuse

Sort each field into required, optional, derived or merely convenient. Give optional collection an honest choice, and never bundle a marketing use into a feature that works without it.

When a new use appears, compare it against several things. These include the original purpose, the notice, and what people expect. Also compare any permission given, the contract, and the legal basis. An internal calculation, a disclosure to a new partner and an automated decision carry different risks. Review them one at a time.

Govern sharing and retention

List every recipient category and the exact fields each one receives. A processor acting on instructions is not the same as an independent recipient making its own decisions. A contract matters, but the transfer logs and the technical configuration have to match it.

Retention follows purpose, legal duties, dispute needs, security and your real ability to erase or anonymize. "Delete when no longer needed" is not a schedule. Use a trigger and an action.

Trigger	Action	Example window

Retention triggers and actions

Failed signup
Close the pending record (days)
Account deletion
Remove the live profile (weeks)
Backup cycle
Let the encrypted copy expire (one cycle)

Those windows are design patterns, not universal periods. Set yours against the purpose you wrote first.

Protect what remains, and honor individual controls

Limit access by role and task. Match authentication to the risk, encrypt where it helps, test recovery, log access, control vendors and patch promptly. Keep production data out of test systems. Protect deletion tools from unauthorized use and from accidental failure.

Individual rights request steps

Explain the scope
Verify identity
State consequences
Give time frame
State exceptions
Provide appeal or complaint route

Security has to follow the actual path. Encrypting a database does nothing for an exported spreadsheet sitting in a support ticket. Strong login security does not limit a vendor's unnecessary access.

People may need to view, correct, download, object to, restrict or delete their information. Which rights apply depends on the law, your role, the person's location and the context. A product toggle and a formal legal request are not the same thing.

Explain the scope, the identity check, the consequences and the time frame. State the exceptions and the appeal or complaint route. Ask for no more identity information than the request requires, and keep a record that the request was handled without holding the full file forever.

Prove accountability

Name an owner for the service, the data, security, and legal review.

Five accountability questions

1What do we hold?
2Why?
3Who can use it?
4When does it leave?
5How do we know the answer is true?

A working program answers five questions fast: What do we hold? Why? Who can use it? When does it leave? How do we know the answer is true?

The browser privacy settings review covers the client side, where cookies, local storage, site permissions and autofill quietly widen collection.

Where location is the field in question, compare precise, approximate, foreground and background geotags before you decide what to keep.

For the account-by-account version of this work, the personal data lifecycle checklist turns each section above into a task with a date.

Common questions

Is all personal data sensitive?

No, and the law does not treat it that way. Sensitivity depends on context, combination, use and the statute that applies. Ordinary fields can become harmful once aggregated or exposed together.

Does encryption make data anonymous?

No. Encryption protects readability for anyone without the key. Whoever can decrypt the data can still connect it to a person.

Is deleting an account the same as deleting every record?

Not always. Transactions, security logs, legal records and backups may be kept for defined reasons. The service should state the scope and the schedule accurately, and you can ask it to.

Who owns privacy work?

Several roles do, and that is the problem. Product, engineering, security, legal, operations and vendors each control part of the lifecycle. Without a named owner per part, no one can answer for the whole.

If a request is refused or ignored, the Office of the Privacy Commissioner of Canada accepts complaints about federal and some provincial matters, and each provincial commissioner handles its own statute. For anything that turns on how the law applies to your facts, ask a licensed lawyer.