Privacy by design: what to store and where

Privacy by design builds data protection into the schema in advance: minimal fields, each with a purpose and a retention period. GDPR Article 25 requires it.

The riskiest thing in your database

Your project’s database can hold anything, but the most dangerous thing in it is data about people: names, phone numbers, requests. If the catalog of services leaks, nothing happens. If the requests leak, it’s a harm to the people and to you. That’s why this part ends with privacy: now you know how data is arranged, and you can decide what to store and how.

This lesson is general information, not legal advice. Laws change and differ from place to place, and for a real project an attorney who works in privacy law checks the texts and the process. Regulators publish free guidance too: the Information Commissioner’s Office (ICO) in the UK, the data protection authorities of the EU countries (the European Data Protection Board lists them), and in the US the Federal Trade Commission and your state attorney general. What you can learn here is to ask the right questions and to build the answers into the schema.

Privacy by design

The idea comes from Ann Cavoukian, Ontario’s privacy commissioner, in the 1990s: protection should be built into the way a system is made, not glued on after the first leak. The European GDPR wrote it into law as Article 25, “data protection by design and by default”. Cavoukian’s seven principles come down to this:

1. Act in advance, not after an incident.
2. The most private settings are on by default.
3. Privacy is built into the design of the system.
4. Nothing is sacrificed: good protection and a well-working site go together.
5. Protection for the whole life of the data, from collecting to deleting.
6. Transparency: people can see what happens to their data.
7. Respect for the person: their interests come first.

Article 25 turns this into two duties. By design: when you decide how to process data, and while you do it, you put in place technical and organizational measures (pseudonymization is the law’s own example) built to carry out the data protection principles, such as data minimization. By default: unless a person chooses otherwise, only the personal data necessary for each specific purpose is processed, and that applies to the amount collected, how far it’s processed, how long it is stored and who can reach it. Those four things are exactly what a database schema decides.

Five steps in a schema

In practice, for a schema, this becomes five steps.

1. Minimum. Collect nothing the purpose doesn’t need. What you don’t collect can’t leak, and you won’t have to protect, keep or delete it. GDPR says personal data must be “adequate, relevant and limited to what is necessary” (Article 5(1)(c)). Virginia’s law says a controller must limit collection to what is “adequate, relevant, and reasonably necessary” for the disclosed purposes, and California’s says collection, use and retention must be “reasonably necessary and proportionate”. A booking form needs a name and a way to reach the person. A date of birth “just in case” isn’t a purpose. Switch fields on and off in the diagram below: the counter shows how much extra you would be holding.

2. A purpose for every field. For every field you must be able to say why it’s there. GDPR calls this purpose limitation: purposes are “specified, explicit and legitimate”, and the data isn’t used in a way that doesn’t fit them. The US state laws say much the same. A phone number taken to answer a request cannot, without a new basis, be put on a marketing list.

3. Retention and deletion. Each group of data needs a retention period and a condition for deleting or anonymizing it: “three years after the request, then deleted”. Data without a period piles up forever, and the responsibility for it stays with you. GDPR calls this storage limitation: no longer than the purpose needs. California goes further and asks a business to tell people how long it keeps each category. The period must be written down, and the deleting should be automatic (a scheduled job), or nobody will remember it.

4. Separation and protection. Personal data is kept apart: requests in a table of their own. Logs, analytics and emails hold only the request number, not the name and phone. Access goes by role: the accountant doesn’t need contacts, and the editor doesn’t need requests (more on authorization in part 6). The connection to the database and the disk are encrypted, and visitors’ passwords are stored not as they are but as hashes (a slow function such as argon2 or bcrypt, plus a salt), as the lesson on authentication explained. The OWASP cheat sheet in the sources is a useful list of measures.

5. Consent as a record. A form has a checkbox, and many people stop there. But when a person comes and asks “what did I agree to?”, you need to show a record: the date and time, the version of the text they agreed to, and the purpose. GDPR is explicit: where processing rests on consent, the controller “shall be able to demonstrate” that the person consented (Article 7(1)). So consent is a row in a table, not a boolean: consents(request_id, given_at, text_version, purpose).

Consent is only one of the legal reasons to process data. GDPR lists six lawful bases (Article 6): consent, a contract (including steps a person asks for before one), a legal obligation, vital interests, a public task, and legitimate interests. Replying to a visitor who wrote to you rests on the second or the last, not on consent. Consent is the right basis for things the visitor could refuse without losing the service, such as a newsletter. In the US the state laws lean on notice and a right to opt out, and they ask for opt-in consent mainly for sensitive data.

Purpose of collecting: book a consultation. Switch on the fields your form would collect. The labels in the diagram are a simplification for the lesson, not legal advice.

• Name personal data
  To know how to address the person.
• Phone personal data
  To get in touch about the request.
• Email address personal data
• City personal data
• Comment (free text) high risk
  People write anything there, including what you did not ask for: details about their health or family.
• Date of birth personal data
  A request does not need it. “Just in case” is not a purpose.
• Social Security or passport number high risk
  High risk: with it someone can act in the person’s name. A request does not need it.
• Health condition special category
• Which service they want not personal
  Not personal data on its own, but next to a name it becomes part of the request.

6 fields collected

5 personal

2 high risk

0 special categories

More than the purpose needs: Comment (free text), Date of birth, Social Security or passport number. What you do not collect cannot leak, and you will not have to protect, keep or delete it.

How long requests are kept: 3 years

Where the database lives

A server in my visitors’ own country or region A server in another country A cloud, country unknown

Retention: The period should follow from the purpose: for example, while the request is being worked on and while a dispute is still possible. Write it down, and what happens when it ends.
Place: The simplest case: the data stays under the law that protects it. Even so, the host is your processor, so keep a contract with it (GDPR Article 28).

Text alternative: the diagram shows that every extra form field (date of birth, an ID number, a free comment) adds personal data and risk without helping the purpose. Each group of data needs a retention period with a condition for deleting, and a place of storage: under GDPR a transfer abroad needs a safeguard, and Russia requires the primary database of its citizens’ data to be in Russia.

Check yourself: why is the “Comment” field riskier than the others?

People fill free text with anything, including details about health and family that you never asked for. The data turns out unexpectedly sensitive, while the protection was built for ordinary data. A hint beside the field, saying what not to write, helps.

What sits in the copies

When a person asks you to delete their data, deleting a row isn’t enough. Data also lives in backups, in server logs (an error saying “could not send the text message to +1 …” wrote a phone number into a file), in analytics, in emails and in exports. Each copy needs its own retention period, and it’s best to keep personal data out of logs altogether. Make the register include the copies: that’s what it is for.

What the law says

The details differ by place. Here are the main frames an English-speaking site meets, and one strict example for comparison.

GDPR (the EU). The General Data Protection Regulation applies to anyone who offers goods or services to people in the EU, or watches their behavior, wherever the site is (Article 3). Personal data is any information about an identifiable person: a name, a phone number, an email, but also an IP address, a photo or a location. The controller decides why and how the data is processed (if your form collects names, that is you, even as a one-person business). A processor handles data on the controller’s behalf: your hosting company, your email service, an embeddings provider. You need a contract with each processor (Article 28). What follows for the database:

• A lawful basis for each purpose (Article 6, above), and stricter rules for special categories such as health, beliefs or biometrics (Article 9). If you don’t need them, don’t ask.
• Purpose, minimum and storage limits (Article 5), which the steps 1 to 3 carry out. Article 25 makes it a duty to build them into the system.
• People’s rights (Articles 15 to 22): to see what you hold, to have it corrected or erased, to restrict or object to processing, and to take it elsewhere. The reply is due within a month. That’s why you must be able to find and delete one person’s data.
• A record of processing (Article 30). Smaller organizations are partly exempt, but a register like the one in this lesson is the easiest way to answer any question about your data.
• A breach must be reported to the authority within 72 hours (Article 33) when it puts people at risk. Fines for the gravest breaches reach 20 million euros or 4% of worldwide annual turnover.

The UK. After Brexit the UK kept the same rules as the UK GDPR, together with the Data Protection Act 2018. The regulator is the ICO. For a site, the practical advice is the same.

The United States. There’s no single federal privacy law for websites in general. There are laws for particular areas (children’s data under COPPA, health under HIPAA, finance under the Gramm-Leach-Bliley Act), the Federal Trade Commission, which acts against companies that break their own privacy promises, a breach-notification law in every state, and, since California started in 2018, a growing list of state privacy laws: California’s CCPA as amended by the CPRA, then Virginia, Colorado, Connecticut, Utah, Texas and many more (the IAPP keeps a tracker). They differ in detail, but they share a core: tell people what you collect and why, limit collection to what is needed, let people see, correct and delete their data and opt out of its sale or sharing, and take extra care with sensitive data. Most apply only above a size: California’s CCPA, for example, covers a business with annual revenue above about 26.6 million dollars, or one that buys, sells or shares the data of 100,000 or more residents or households, or that earns half its revenue from selling or sharing it. A one-person practice may fall below every line, but whether it does is a question for an attorney, and customers expect the same care either way.

Data localization and transfers. Where may the database sit? GDPR does not require data to stay in the EU. Chapter V says it may leave only with a tool: an adequacy decision (the European Commission has found some countries adequate, and since 10 July 2023 a US company that joins the EU–US Data Privacy Framework counts), standard contractual clauses between you and the receiver, or another safeguard. The US state laws have no localization rule, though your privacy notice should say who receives the data, and some government contracts and regulated sectors add rules of their own.

Russia, for comparison. Russia’s 152-FZ is the strict case. Its Article 18, part 5, says that when personal data of Russian citizens is collected, including over the internet, recording, storing and retrieving it must use databases located in Russia. A foreign server can’t be the primary store, and a copy abroad is a separate transfer procedure. In 2016 the regulator blocked the LinkedIn site in Russia for breaking this rule. China and some other countries have localization rules of their own. If your visitors are in a country with such a rule, the host’s location is a legal question from the first day.

Whatever the law, one habit pays off everywhere: know which country your host stores the data in, and write it in the register.

Practice

You’re in the era of 2022: protecting data is turning from a wish into something regulators check. Draw up an inventory of your project’s data and add consent to the schema.

The page has a register table with four rows (name, phone, comment, the people on the site) and a box for SQL. Fill in the register, say what you decided not to collect, where the main record sits and how personal data is kept apart, and create a consents table with a date, the version of the text and a purpose.

What was wrong before

In the 2010s, requests from a site usually went by email to the owner’s personal mailbox, in plain text, and piled up there for years: nobody knew how many, who had access, or when to delete them. Forms loved “required” fields just in case, and consent was a sentence in small print at the bottom of the page. Today that’s not only a bad habit but a risk: data leaks from a mailbox just as it does from a database, and there’s nothing to prove consent. The register and the consents table solve both problems.