Personal Data Protection

Writing things down about people is old, but in the era of paper ledgers that writing stayed in one place. Handing a customer list to someone else meant physically moving it, and whatever moved away was gone from the original. Computers inverted that property. Once copying cost essentially nothing, the same list could sit in ten places at once, and a file that left the building could never be called back.

What people experienced next usually took one shape. Loan ads start arriving from numbers you don't recognize, and you cannot remember which company you gave the number to. You signed up for dozens of services over the past few years, and nothing is left of which boxes you checked at the time. The one person who could not see how far the information had spread was the person it described.

The companies collecting it weren't acting in bad faith either. A date-of-birth field on the signup screen might come in handy for age-bracket analysis later. An email address printed straight into the logs makes an outage easier to trace. Marketing points out that the addresses are already on file, so why not announce the new feature to them. Engineering never writes the deletion code, because deleted data is hard to recover if someone asks for it. Each call is reasonable on its own, and together they leave information nobody ever confirmed a need for, piling up with no purpose and no expiry.

So the rules start by moving one thing. Information a company collected is not treated as the company's property; the person is the owner and the company is borrowing it for as long as it is needed. Once it's a loan, the questions that follow are fixed. Did you say up front what you were borrowing it for? Are you using it outside what you said? Are you still holding it after you're done? In practice the first and third are where teams get caught. If you still have the records of a closed account three years on, you need an answer for why three years.

As these rules became law country by country, breaking them acquired a price. Europe began calculating fines against worldwide revenue in 2018, and Korea wrote revenue-based penalties and a duty to report breaches into its own law. Deletion looks like a loss rather than a feature to the people building the product, so until that price existed it rarely climbed anyone's priority list.

The terms under personal data protection fall into seven groups: who appears in the relationship (parties), what gets published (documents), on what footing you may handle the data (lawful bases), what lines to hold while handling it (principles), what the owner can demand (rights), what is required when data leaves the company (transfers), and what to do once it has leaked (incidents).

Parties splits the three roles in this relationship. The dividing line is who decides the purpose.

1. Data subject — the person the information belongs to. Every individual user signed up to Pagedeck is one. All the rights described further down attach to this role.
2. Data controller — the side that decides what to collect, why, and where to use it. The test is deciding rather than touching, so a company that has someone else run the servers still holds this role as long as it set the purpose.
3. Data processor — the side that handles data on instruction. A vendor that sends email on your behalf, or an outsourced desk that answers customer tickets. It sets no purpose of its own and works only inside the scope it was given, and when something goes wrong the responsibility toward the data subject stays with the company that delegated.

Documents covers what the relationship declares in public. A privacy policy states what is collected for which purpose, how long it is kept, and who it is handed to or shared with. The law fixes which items it must contain, so the format is settled, and it has to sit somewhere users can find at any time. It should change whenever the product changes, which is exactly where it slips — a new analytics tool goes in and the policy keeps the wording it had two years ago.

Lawful bases splits the footing on which you may handle data at all. There are two. Consent means getting permission in advance, after saying what is collected, for what purpose, and for how long, with items the service genuinely needs separated from items it doesn't so the person can choose. A signup screen that blocks registration unless you accept marketing email fails on that point. Legitimate interest is a basis recognized without consent — checking access logs to stop fraudulent signups, for instance — and only where the company's need outweighs the disadvantage to the person. Europe leans on it broadly while Korea recognizes a narrower range, so identical processing can land differently depending on the country.

Principles sets the lines to hold while handling data. There are three, and they bite at the moment of collecting, the moment of using, and the moment of disposing.

1. Data minimization — collect only what the purpose requires. A document collaboration tool rarely has a reason to ask for gender and date of birth at signup. "We might use it later" does not count as a reason.
2. Purpose limitation — don't use data outside the purpose you stated. Taking a phone number collected for billing and using it to promote a new feature is the classic violation. Using the same data elsewhere means establishing a basis for that new purpose.
3. Retention period — the ceiling on how long you may keep something, set separately per item. Some are fixed by law, like payment records that must be held for a set number of years; others, like access logs, are whatever the company decides it needs. A deadline with no job that actually deletes on schedule is a deadline that exists only in the document.

Rights collects what the data subject can demand of the company. Two are central. The right to erasure is the right to have your information deleted; the right to access is the right to see what is held about you and how it is being used. Both carry legal deadlines, so an intake channel and a handling procedure have to exist before the request arrives. Where products get caught is the scope of deletion. Removing one row from the members table leaves the same person scattered across payment records, support tickets, events sent to an analytics tool, and backups. If you haven't decided in advance how far deletion goes and what stays because the law requires it, you cannot decide it on the day the request lands.

Transfers covers data leaving the company. Cross-border transfer is processing personal data abroad — hosting on an overseas cloud, or using a foreign analytics service — which means most teams are doing it even when they think they serve only a domestic market. You have to say which country the data goes to and who receives it, and have a basis for the move. A data processing agreement (DPA) is the contract with the vendor doing the handling: clauses that it won't use the data beyond what it was asked to do, won't subcontract further on its own, and will report an incident immediately.

Incidents covers what happens after data is already out. Breach notification is the duty to inform the supervisory authority and tell the affected users. Many rules run on a 72-hour clock from the moment you become aware, which means working out within three days what leaked and how much, then saying so. Meeting that clock depends on knowing which logs exist where and who makes the calls, and both have to be settled before the incident.

The seven groups run in one line. Parties fixes who is responsible, lawful bases establishes the footing, principles draws the lines for the handling itself, documents declares all of it publicly, rights opens the channel for the owner to check and undo, transfers attaches conditions on the way out, and incidents takes over when every one of those has failed. Patch the policy document while leaving the signup screen and the deletion code untouched and the line breaks at the first square.

"Why are we asking for this field? If nothing uses it, let's drop it."

Every collected item needs somewhere it is actually used.

"Don't send the event email to that list. We didn't get consent for that purpose when we collected it."

The same data needs a fresh basis before it goes outside the purpose you declared.

"Email addresses are printed straight into the logs, and there's no retention limit on them."

Nothing has gone wrong yet, but a leak would reach much further than it needs to.

Pagedeck first looked at this properly because of an enterprise security questionnaire. The one Sofia brought back just before signing had fields for collected items, retention periods, and a list of data going overseas, and nobody in the company knew the answers. When Theo dug through the code, the signup screen turned out to collect six items where the policy document listed four, and support tickets from deleted accounts were still sitting there.

Mia started the cleanup with a single table: why each item is collected, where it is stored, when it is deleted. Filling it in revealed that no feature used the date-of-birth field at all. Ravi read the table and split the mailing list in two, because people who had opted into product announcements and people who had consented to marketing were mixed together. The last thing Grace settled was who owns the table. If nobody updates it when a feature ships, the conclusion that day went, you land in the same place three months later.

The most common mistake is thinking consent covers anything. Checkboxes line the signup screen, the user ticked them, so permission was granted — that reading comes easily. But consent is only one basis among several, and even when you have it, it works only inside the purpose you disclosed. Consent bundled so that everything is mandatory, or taken without saying what the data is for, is likely invalid from the start. Leave the mistake in place and the company pours effort into longer consent wording while continuing to collect fields it doesn't need and doing nothing about use outside the stated purpose. What fails an actual audit is rarely whether consent was taken; it's whether the purpose taken matches the use.

The second is treating this as a legal team problem with no bearing on people building the product. It arrives wrapped in statutes and fines, which makes it look like someone else's department. But the place where compliance is actually decided is the screen and the code, not the document. Product decides which fields appear at signup, engineering decides what goes into the logs and when it is deleted, marketing decides which list receives the email. Legal can write those decisions up afterward; it cannot reverse them. Leave this one in place and every review starts after the fact, opening with how to delete two years of accumulated data.