Personal data, backups, metadata, and retention

Some rows in a database represent products, store locations, or order totals. Other rows represent people.

A database may process both as columns and values, but customers, laws, and organizations recognize an important difference. Information connected to a person can affect their privacy, security, finances, and reputation.

So handling that information responsibly requires more than storing it correctly.

Teams must decide which data they should collect, who may access it, how it should be protected, how long it should be kept, how it can be recovered, and when it should be deleted.

The central principle is:

Data about a person should be treated as something entrusted to the organization, not merely something the organization possesses.

What is PII?

PIIConcept · lights on your mappersonally identifiable informationPersonally Identifiable Information, pronounced “P-I-I.” Information that can identify a person directly or can reasonably be connected to a particular person: name, email, phone, address, birthdate, government ID, account identifiers, precise location, device identifiers, financial information. The word signals that data deserves additional scrutiny. It changes who may see a file, where it may be stored, and which rules apply. stands for Personally Identifiable Information.

It is usually pronounced letter by letter:

“P-I-I”

PII generally refers to information that can identify a person directly or can reasonably be connected to a particular person.

Examples may include:

• Full name
• Email address
• Phone number
• Home address
• Birthdate
• Government identification number
• Account identifier
• Precise location information
• Device or online identifiers
• Financial account information

Some information identifies a person directly.

For example:

Other information may become identifying only when combined with additional data. A location coordinate, device identifier, or unusual purchase history may not contain a person’s name, but the organization may still be able to connect it to a particular customer. So context matters.

PII and personal data

Different organizations and laws use different vocabulary.

In the United States, teams commonly use PII, while the European Union’s General Data Protection Regulation, or GDPR, uses the broader term personal data.

Personal data generally includes information relating to an identified or identifiable person, and this can include direct identifiers as well as information that could help identify someone indirectly.

You do not need to memorize legal definitions yet.

The useful beginner model is:

Personal information is data that identifies, describes, relates to, or can reasonably be connected to a person.

Exactly which rules apply depends on the data, organization, users, industry, and jurisdiction.

Sensitive personal data

Some personal information creates greater risk if exposed or misused.

Examples can include:

• Passwords and authentication credentials
• Financial information
• Government identification numbers
• Medical information
• Biometric data
• Precise location history
• Information about children
• Certain demographic or identity information

Laws use different names and categories for especially sensitive information, but the important product and engineering lesson is that not all personal data should receive identical treatment.

A public display name and a bank-account number may both relate to a person, but the consequences of exposure are very different, and systems may therefore apply stronger restrictions to more sensitive fields.

Why the term changes a conversation

Suppose someone asks:

“Can you export the customer table and send it to me?”

The first useful question is:

“Does the export contain PII?”

If it does, that changes how the request should be handled.

The team may need to consider:

• Whether the requester is authorized
• Whether every field is necessary
• Whether sensitive values should be removed
• Whether the file should be encrypted
• Where it may be stored
• How it may be shared
• When it must be deleted
• Whether the export should be logged
• Whether legal or compliance review is required

The word PII is useful because it signals that the data deserves additional scrutiny.

Data minimization

A foundational privacy principle is data minimization.

Data minimization means collecting, using, and retaining only the information reasonably necessary for a defined purpose.

The coffee application, for example, needs an email address to send a receipt but may not need the customer’s birthdate, employer, or precise location history.

Before collecting information, teams should ask:

• Why do we need this?
• What product function depends on it?
• Could we accomplish the goal with less information?
• How long will we need it?
• What risk do we create by storing it?
• Who will be allowed to use it?

Collecting more data can appear valuable because the company may use it later, but every additional field creates responsibilities involving security, privacy, access, retention, accuracy, and deletion.

A useful principle is:

Data the company never collects cannot later be leaked from its systems.

Access control

Personal data should not be available to every employee or system merely because it exists in the database, so access control determines who or what may view, change, export, or delete information.

This applies the authentication and authorization distinction from Module 6.

First, the system authenticates the employee or service:

Who are you?

Then it authorizes the requested action:

Are you allowed to view this customer’s information?

A support agent may need access to a customer’s email and recent orders but not to the complete payment credentials.

A marketing analyst may need aggregated customer behavior but not individual names.

A database administrator may have broad technical access, but that access should still be governed, monitored, and limited to legitimate work.

Least privilege

An important access-control principle is least privilege.

Least privilege means giving a person or system only the access necessary to perform its responsibilities.

For example, a customer can view their own profile, and a support agent can view the customers assigned to a case. A refund service can update payment status but cannot read unrelated profile fields. An analytics tool receives anonymized or limited data rather than the complete production database.

Broad access may feel convenient, but it increases the damage that mistakes, compromised accounts, or misuse can cause, so the goal is to let employees do their jobs with no more power than those jobs require.

Audit logs

For important data, companies often record who accessed or changed it, and that record of significant actions performed in a system is called an audit log.

It might record:

Audit logs help organizations investigate incidents, detect suspicious behavior, and understand how data changed. They also help demonstrate compliance, resolve customer disputes, and hold users and systems accountable.

The audit log is itself sensitive data because it can reveal employee behavior, customer activity, and system details. So it must also be protected.

Privacy rights

Privacy laws may give individuals rights relating to their personal information.

Depending on the law and situation, these can include rights to:

• Learn which information is collected
• Access copies of their information
• Correct inaccurate information
• Object to certain uses
• Limit certain processing
• Move information to another provider
• Request deletion
• Withdraw certain consent

The GDPR is one widely recognized privacy regulation, but different countries, states, and industries have their own requirements as well.

The specific rights and obligations vary.

For a technical team, the practical question is:

Can our systems find, export, correct, restrict, and delete the relevant information when required?

A legal right becomes an engineering requirement when the company must carry it out across databases, backups, analytics systems, and third-party services.

Deletion is not always absolute

People sometimes describe privacy law as giving every user an unconditional right to have all information erased. The reality is more nuanced.

An organization may sometimes need to retain certain records for reasons such as financial reporting, fraud prevention, legal claims, security investigations, contractual obligations, regulatory requirements, or required transaction histories.

For example, deleting a customer account may not require erasing every legally required financial record connected to past purchases. The company may instead remove unnecessary profile information while retaining limited records it is required to keep.

The important lesson is:

Deletion rules depend on the purpose of the data and the obligations attached to it.

Product, legal, compliance, data, and engineering teams often need to define these rules together.

Cookies and privacy

In Module 5, you learned that cookies can store identifiers and support sessions, preferences, and analytics.

Cookie banners are one visible part of the privacy landscape.

Some cookies are necessary for a requested service, such as maintaining a login session. Others may support analytics, advertising, personalization, or cross-site tracking.

Different rules may apply depending on the type of cookie, the location of the user, and how the information is used.

The connection to the database is that cookie identifiers can be linked to stored user profiles and activity, so a seemingly random browser identifier may become personal information when the company connects it to a known customer.

Privacy applies to the full data flow:

Protecting data from loss

Privacy covers more than preventing unauthorized access. Organizations must also protect important information from accidental deletion, corruption, hardware failures, software bugs, and disasters, and one method is creating backups.

What is a backup?

A backupConcept · lights on your mapbackupA separate copy of data, kept so the original can be recovered after loss or damage. The critical word is separate: a copy destroyed by the same incident as the live database protected nothing. is a separate copy of data created so that the original information can be recovered after loss or damage.

A database backup might contain the complete database, changes made since an earlier backup, transaction logs, snapshots from a particular time, or copies of specific tables or systems.

Backups may be stored on separate storage, in another data center, in another cloud region, in a different cloud account, or in offline or protected storage.

Behind each of those options is the same idea, separation. If the live database and its only backup are destroyed by the same incident, the backup did not provide meaningful protection.

Backup versus replication

A backup is not the same as a live replica.

A replica is another database copy kept synchronized with the primary database, often to improve availability or serve additional reads.

If a user accidentally deletes important records, that deletion may quickly be copied to the replica.

So the replica now contains the same mistake.

But a backup preserves recoverable data from an earlier point in time.

This distinction is useful:

Replication helps a system continue operating when infrastructure fails.

Backups help recover information that was lost, corrupted, or incorrectly changed.

A resilient system may use both.

What is restore?

A restoreConcept · lights on your maprestoreRecovering data from a backup. The half everyone forgets: a backup is only useful if it restores successfully, which is why teams rehearse restores rather than assuming the copies will work. is the process of recovering data from a backup.

Creating backups is only the first step. The organization must also know:

• Whether the backup is complete
• Whether the backup is corrupted
• How long recovery takes
• Which systems depend on the database
• Whether applications can use the restored version
• How to handle changes made after the backup
• Who has authority to begin a restore

A commonly repeated engineering principle is:

A backup is useful only if it can be restored successfully.

Teams therefore perform restore tests, confirming before an emergency arrives that the copies will work.

Recovery Point Objective

How much recent data can the business afford to lose?

This is described using the Recovery Point Objective, or RPO: the maximum acceptable amount of data loss measured in time.

If the RPO is 24 hours, the business has accepted that a severe disaster could require restoring data from as much as 24 hours earlier.

If the RPO is five minutes, the recovery design must preserve data much more frequently.

A simplified interpretation is:

RPO asks: How far backward can we afford to rewind?

Backup frequency influences RPO, but other technologies such as transaction logs and continuous replication can also affect it.

Recovery Time Objective

How long can the system remain unavailable while being restored?

This is the Recovery Time Objective, or RTO. If the RTO is four hours, the organization aims to restore service within four hours after a major incident.

A simplified interpretation is:

RTO asks: How long can recovery take?

RPO and RTO answer different questions:

• RPO: How much data loss is acceptable?
• RTO: How much downtime is acceptable?

Both are business decisions supported by technical systems, and a payment platform may require much stricter recovery targets than an internal archive used once a month.

Backups contain sensitive data too

A backup may contain the same personal and confidential information as the live database.

That means backups also require access controls, encryption, monitoring, retention rules, secure storage, deletion processes, and restore testing.

Removing a customer’s information from the live database may not immediately remove it from every historical backup, so organizations need policies for how deleted data ages out of backups and how restored systems avoid unintentionally reactivating information that should remain deleted.

Because a backup is another copy of the data, it carries the same privacy and security responsibilities.

What is metadata?

MetadataConcept · lights on your mapmetadataData about other data: when a record was created and by whom, a photo’s timestamp and location, an email’s sender, recipient, and delivery route. Metadata helps systems organize, search, govern, and understand information, but it can itself reveal sensitive patterns (relationships, routines, locations) even when the content stays hidden. means data about other data.

For a photo, metadata might include when it was taken, which device created it, its file type and dimensions, its geographic location, who uploaded it, and when it was modified.

For a database record, metadata might include when the record was created and last updated, which system created it, which user changed it, and which version of the schema produced it.

An email’s metadata might include the sender, recipient, timestamp, subject line, delivery route, and message size.

Metadata helps systems organize, search, govern, and understand information.

Metadata can still be sensitive

Metadata may sound less sensitive than content, but it can reveal significant patterns.

Imagine a system knows who contacted whom, at what time, how frequently, from which location, and using which device.

Even without reading the message body, those patterns may reveal relationships, routines, travel, employment, or personal circumstances, and photo metadata may similarly expose the location of a person’s home even when the image itself does not visibly show an address.

A useful principle is:

Data about an interaction can be sensitive even when the interaction’s content is hidden.

Metadata must therefore be considered when classifying and protecting information.

What is data retention?

Data retentionConcept · lights on your mapdata retentionThe practice of deciding how long information should be kept, and when it should be deleted. Not “keep everything forever”: a deliberate policy connecting business needs, customer expectations, legal requirements, security, and cost. Different data gets different periods, from temporary logs kept for days to financial records kept for legally required years. is the practice of deciding how long information should be kept.

Different data may require different retention periods.

Examples include:

• Temporary logs kept for several days
• Support conversations kept for a defined service period
• Financial records kept for legally required years
• Inactive accounts deleted after a stated period
• Security records kept long enough to investigate incidents
• Backups rotated and deleted according to a schedule

Retention is not “keep everything forever” but a deliberate policy connecting business needs, customer expectations, legal requirements, security, and cost.

Why keeping data forever is risky

Organizations sometimes keep information because storage appears inexpensive and the data might become useful someday.

But indefinite retention creates costs and risks.

Old data can be exposed in a breach or accessed inappropriately. It can become inaccurate, confuse analytics, and increase legal obligations. It can also make deletion requests harder, increase storage and processing costs, and be difficult to classify and govern.

The longer data exists, the longer the organization remains responsible for protecting it.

A useful principle is:

Information should have a defined reason to exist and a defined point at which that reason ends.

Retention and deletion across systems

Deleting one database row may not remove every copy.

The same customer information might exist in the production database, in backups, in application caches, and in search indexes. Copies may also live in analytics systems, internal tools, marketing platforms, support systems, logs, and third-party services.

A complete deletion workflow may need to send requests to several systems and track whether each one succeeded, which returns to Module 6’s integration challenges.

Deletion itself can become a distributed workflow involving API calls, retries, idempotency, audit records, timeouts, and vendor contracts.

The company needs to know where data travels before it can reliably govern or delete it.

Anonymization and pseudonymization

Organizations may reduce privacy risk by changing how identifying information is stored. Pseudonymization replaces direct identifiers with another value while preserving a way to reconnect the information under controlled conditions.

For example: Erik Smith → customer_88

The activity is no longer labeled with Erik’s name, but another protected system may still connect customer_88 back to him.

Anonymization attempts to transform information so that individuals can no longer reasonably be identified.

True anonymization can be difficult, especially when datasets contain detailed behavior that can be combined with other information, and removing names alone does not necessarily make data anonymous.

The useful distinction is that pseudonymized data can still be reconnected to a person, while properly anonymized data should not be reasonably reconnectable.

Pseudonymized information is generally still treated as personal data because the connection remains possible.

Seeing the full data lifecycle

Imagine Erik creates a coffee account. The application collects his name, email, and order history.

The company should decide:

1. Why each field is needed.
2. Which system is the source of truth.
3. Who may access each field.
4. Which systems receive copies.
5. How the information is encrypted and monitored.
6. How often the database is backed up.
7. How quickly the company must recover after a failure.
8. How long each category of data should be retained.
9. How Erik can access or correct his information.
10. What happens if he requests account deletion.
11. Which information must still be retained for legitimate obligations.
12. When remaining copies and backups will age out.

This sequence is sometimes called the data lifecycle:

Responsible data management considers the entire lifecycle, from the moment a row is inserted into a database to the day the last backup copy ages out.

The mental model to remember

PII is information that identifies or can reasonably be connected to a person.

Different laws may use broader terms such as personal data.

Data minimization means collecting and retaining only what is reasonably necessary.

Access control determines who or what may use information.

Least privilege limits access to what is needed for a defined responsibility.

An audit log records important actions involving systems and data.

A backup is a recoverable copy of data.

A restore recovers data from that copy.

RPO asks how much recent data the organization can afford to lose.

RTO asks how long recovery can take.

Metadata is information about other data and can itself reveal sensitive patterns.

Data retention determines how long information should be kept and when it should be deleted.

You should now understand that protecting data means more than preventing database failure. It means controlling collection, access, copies, recovery, retention, and deletion throughout the data’s lifecycle.