Database Encryption Is Not Data Minimization

“The customer table is encrypted, so keeping the extra fields is fine.”

Put that down before it gets promoted from a storage setting to a privacy programme.

Database encryption is not data minimization.

Encryption protects data that remains.

Data minimization decides whether your data should have been collected, linked, copied, retained or reused in the first place.

Those aren’t rival controls.

They operate at different layers.

Transparent data encryption is a storage protection control.

SQL Server TDE encrypts data and log files at the page level, using a database encryption key protected by a certificate.

It encrypts and decrypts during I/O, transparently to your application, and automatically encrypts backups of an encrypted database.

Useful.

Necessary in many environments.

Still entirely concerned with records that already exist.

Privacy engineering begins earlier.

For every field: what purpose requires it, what legal basis supports that purpose, how much granularity does it need, who owns it, which systems receive it, and when does its retention period end?

An encrypted table with an unnecessary birth date, an old address, a tracking identifier, a marketing segment and unbounded history is still a table holding all of those things.

Putting valuables in a better safe does not explain why you kept a garage full of them.

1. “But the Fields Might Help Analytics Later.”

Later isn’t a purpose.

It is a shrug wearing a roadmap.

Minimization design evaluates each field against the stated purpose.

Is it required?

Does it need this granularity?

Does it need to persist this long?

That decision belongs at schema design for new systems, and, much less pleasantly.

During retrofit for existing ones.

The retrofit is difficult for a real reason.

Before you can remove a field, you have to trace every downstream consumer.

A warehouse transformation.

A log pipeline.

A CSV for an old report.

A marketing pixel.

A SaaS integration.

A backup snapshot.

An export sent to a partner.

Which is why a data inventory maps both systems and flows.

An inventory of what engineering intended to provision is not an inventory of what you hold.

The reporting question isn’t “could this exact identified record conceivably be useful?”

Almost anything could.

The question is whether your report needs the raw field, a coarser version, an aggregate, or a shorter-lived record.

Privacy work gives that distinction a number.

In k-anonymity, k is the minimum number of records sharing every quasi-identifier combination.

Raising k usually means reducing resolution: a five-digit ZIP becomes a three-digit prefix, an exact age becomes a ten-year band, outliers are suppressed.

Your database control didn’t make that choice.

Your data design did.

And no, there is no universally correct retention period to paste into a policy.

Every category needs a period tied to why it was collected, and a deletion mechanism that executes when it expires.

“Maybe analytics later” is not a retention schedule, any more than “maybe a breach later” is an incident-response plan.

2. “But Only Production Administrators Can Query Them.”

Then restrict production administrators.

That is the right answer to the access question.

It isn’t an answer to the collection question.

RBAC is your table- and object-access layer.

A role gets privileges such as SELECT on one table and no access to another.

It is coarse-grained.

A role that reads the customer table reads every row in it.

Least privilege exists only if grants are withheld by default and over-broad roles get reviewed rather than quietly fossilized.

RLS is the row-filter layer on top of that.

PostgreSQL enables it with `ALTER TABLE …

ENABLE ROW LEVEL SECURITY`, and absent an explicit policy it applies default deny.

A multi-tenant policy such as USING (tenant_id = current_setting(’app.tenant_id’)) limits a connection to its tenant’s rows even when the query asks for more.

Policies can be permissive with OR, or restrictive with AND.

Table owners and superusers bypass RLS unless FORCE ROW LEVEL SECURITY is configured.

Which is exactly why the distinction matters.

RBAC answers: can this role touch this table?

RLS answers: which rows can this connection see?

Neither answers: why did the table retain this field after the purpose ended?

PCI DSS keeps these duties separate.

Requirement 7 restricts access by documented business need.

Requirement 8 requires unique IDs and, in PCI DSS 4.0, MFA broadly for administrative and cardholder-data-environment access.

Requirement 10 requires logging and active monitoring of access.

Those controls reduce the chance and impact of improper access to retained cardholder data.

They do not convert “we might use it” into a documented business need to retain it.

A narrow key to an unnecessary filing cabinet is still a narrow key to an unnecessary filing cabinet.

3. “But the Backup Is Encrypted Too.”

Of course it should be.

TDE protects data and log files at rest, and a backup from an encrypted database is automatically encrypted too.

The protecting certificate has to be backed up separately, or you end up with an encrypted database you cannot restore.

That is an operational control with a very real failure mode.

It is still not deletion.

An encrypted backup is a retained copy.

A replica is a retained copy.

A warehouse fed from the primary database is a retained copy.

A log pipeline that records identifiers is a retained copy.

A CSV exported for a one-off report has, with impressive speed, become a retained copy in somebody’s folder.

A third-party SaaS tool is a retained copy in somebody else’s system.

So your data inventory isn’t a database-schema diagram.

It catalogues production databases, warehouses, log pipelines, SaaS tools, backup snapshots, and the flows among them.

What originates a field.

What copies or derives from it.

What sends it to a vendor or partner.

The deletion test follows the same route.

Pick a field.

Trace it from origin through primary, replica, analytics, backup, export and third party.

Confirm purpose, retention period, deletion mechanism and evidence of execution at each stop.

If your record disappears from the production table and remains in the analytics warehouse or a snapshot, your workflow did not complete.

It completed a demo.

Encryption is valuable precisely because backup media and storage are exposure paths.

It doesn’t cause retained records to evaporate on schedule.

Cryptography has many gifts.

Administrative telepathy is not among them.

4. “But We Pseudonymized the Identifier.”

Pseudonymization can reduce direct exposure.

It does not automatically make a dataset anonymous, and it does not excuse unbounded retention or secondary use.

The failure is usually in the words “only this field identifies someone.”

Identity can be reconstructed from combinations of ordinary attributes.

Latanya Sweeney’s 2000 finding showed that sex, birth date and ZIP code uniquely identified 87% of the U.S. population.

A table without a name column can still be very much about named people, when it carries the surrounding facts.

Which is why k-anonymity has a formal parameter instead of a comforting adjective.

k is the minimum group size sharing every quasi-identifier combination in a release.

A dataset with those three ordinary attributes effectively starts around k of 1 for much of the population.

Raising k can reduce identity disclosure risk.

It does not prevent attribute disclosure when everyone in a group shares the same sensitive value.

Nor is k comparable to differential privacy’s epsilon.

Epsilon describes a mechanism, and composes across overlapping queries, so systems track a cumulative privacy budget.

Apple’s 2017 methodology set epsilon to 4 for emoji-suggestion frequency collection and 4 for Safari per-domain energy-drain monitoring.

Those are documented deployment choices.

Not a conversion chart for “anonymous enough.”

The practical instruction is much less magical.

Test reidentification risk before describing data as de-identified.

Examine quasi-identifiers, possible external linkage, group homogeneity and the downstream use.

A token in place of an identifier changes a linkage surface.

It doesn’t make the rest of the row forget who it describes.

5. “But Deletion Would Break Historical Reporting.”

Then historical reporting needs an explicit design.

Not a permanent exemption stamped on your production record.

Purpose limitation and retention constrain different things.

A purpose tag says which declared purposes may use a field.

It has to be enforced at the point of use, a query-time check that stops marketing reading a field collected for fraud detection, a data-access layer that requires a declared purpose, a third-party export that carries technical and contractual use restrictions.

Retention says how long the field may remain.

Every field that survives minimization gets a period tied to its purpose, and a deletion mechanism that executes at expiry.

A purpose tag that sits only in a catalogue limits nothing.

A retention policy that sits only in a PDF deletes nothing.

The Berlin Commissioner’s October 2019 action against Deutsche Wohnen SE is a clean example.

The company had no established process to delete or review tenant data, including tax, employment and health information.

When it was no longer needed.

A 2017 audit identified the problem.

A 2019 re-audit found the organization still could not demonstrate a database cleanup, or a legal basis for continued storage.

The point isn’t that old data is automatically forbidden.

The point is that “we have history” isn’t a mechanism.

Historical analysis may justify a coarser field, an aggregate, or a separately governed retention period.

It does not make raw identified history immortal because a future dashboard might appreciate the option.

6. “But Privacy Is Handled by the Legal Team.”

Legal can establish obligations, lawful bases and policy.

It cannot make an unenforced purpose tag block a query.

This is where privacy engineering either becomes a system property or stays a sentence in a notice.

The field needs an owner.

The purpose needs to travel with the field, or be available to the point deciding its use.

Your data-access layer, query policy, export workflow and third-party contract all need to enforce what the declaration says.

Consent creates the same engineering problem in another form.

Recording a choice is capture.

Ensuring that choice reaches the analytics pipeline, the advertising exchange, and every third party already receiving the associated data is propagation.

The IAB Europe Transparency and Consent Framework, announced in November 2017, exists to standardize signals across online advertising.

A standardized signal is not proof that every recipient honoured it.

Which is why the work is called consent plumbing rather than consent vibes.

The division of responsibility is uncomplicated.

Privacy and legal define permissible purposes and constraints.

Database and platform teams implement storage, access, audit, tokenization, encryption and deletion.

Product and data teams own the field and its downstream uses.

No group gets to throw your record over a boundary and declare your boundary a control.

HIPAA makes the non-substitution visible.

Under 45 CFR §164.312(b), audit controls for systems containing PHI are required: you record and examine activity.

Encryption is addressable rather than flatly required for a closed, internally controlled network where documented equivalent controls apply, though open-network data is expected to be encrypted.

PCI DSS Requirement 3, by contrast, covers stored account data through encryption, truncation or tokenization, and also says to minimize what is retained.

One framework is not a substitute for the other.

And neither makes policy text execute itself.

7. No, This Does Not Mean Encryption and Access Control Are Optional.

They aren’t.

Use TDE or the applicable at-rest control.

Back up its protecting certificate.

Configure TLS separately for database connections, because TDE does not touch the network layer.

Use RBAC for table and object privileges.

Use RLS where a shared table needs per-row boundaries.

Audit reads and administrative changes.

Give every administrator a unique ID, and constrain roles by documented business need.

PCI DSS’s numbered structure helps here.

Requirement 3 protects stored account data and minimizes retention.

Requirement 4 protects cardholder data in transit over open public networks.

Requirement 7 limits access by business need.

Requirement 8 establishes identity and MFA requirements.

Requirement 10 logs and actively monitors access.

Five requirements.

Several layers.

No invitation to declare one of them the whole programme.

Encryption reduces exposure when somebody obtains storage they should not have.

Access control reduces who can query retained data.

Audit logging produces evidence of access for review.

Minimization reduces your records, copies and linkage any of those controls have to carry.

Security controls protect retained data. Privacy engineering decides whether and how much retained data exists.

The opposite overclaim would be just as foolish.

Deleting fields does not make an unauthenticated database safe.

In the February 2019 Verifications.io exposure, an unauthenticated MongoDB instance held roughly 150 gigabytes.

Approximately 763 million unique email addresses.

Around 798 million total email records.

About 4.1 million phone numbers.

About 6.2 million business lead records.

Names, ZIP codes, physical addresses, IP addresses, dates of birth, gender and marketing-segment data appeared in the broader dataset.

No exploit was necessary.

No stolen credential.

Authentication was absent.

So the correct response is not to choose between collecting less and protecting what remains.

It is to stop pretending either one performs the other’s job.

8. What You Should Actually Do

Start with the field, not the database product. For each field, document purpose, legal basis, data class, owner, required granularity, downstream consumers and retention period.

Reject collection that cannot name an owner and a purpose.

“Available in the event analytics becomes interesting” is neither.

Maintain a data inventory that includes production databases, replicas, warehouses, log pipelines, backup snapshots, SaaS tools, exports, vendors and partners. Map where each field originates, is copied, is derived and is sent.

Repeat the mapping whenever a new pipeline, reporting export or pixel appears.

The systems people forget are the systems deletion cannot reach.

Enforce purpose at use time. Tag fields with allowed purposes.

Make a query-time check, data-access layer or export control require the relevant purpose.

Where consent is the legal basis, propagate its state downstream rather than treating a preference-centre timestamp as proof of enforcement.

Set retention schedules by purpose, then make them execute. Test an end-to-end deletion workflow against primary tables, replicas, analytics stores, logs, snapshots, backups, exports and recipients.

Keep evidence that the mechanism ran.

The scheduled job is the control.

The retention-policy slide is a decorative description of the control somebody intends to build.

Apply database controls to what remains. Default-deny RBAC.

RLS for the row boundary a shared role cannot provide.

Minimal query roles.

Audited reads.

Unique identities.

Tokenized identifiers where the architecture supports it.

Encryption of data, logs and backups at rest.

TLS for client connections.

And a retained, tested certificate for restoring TDE-protected databases.

Test reidentification before calling a release de-identified. Pseudonymization, a higher k and a chosen epsilon each address different properties.

None of them lets a team skip the question of whether attributes link back to people, or whether the data still needs to exist.

9. The Model Is Not Complicated.

Database security is your control plane around retained records.

Authentication, RBAC, RLS, encryption at rest, TLS in transit, keys, audit logs.

Privacy engineering is the decision plane before and through retention.

Inventory, minimization, purpose limitation, consent propagation, retention, deletion, reidentification risk.

Encryption makes a retained database harder to read when storage is exposed. Minimization makes the database contain less worth exposing.

Use both.

Do not tell your organization that encrypted surplus is no longer surplus.

That is how a customer table becomes an archaeology site.

Exquisitely protected, impeccably audited, and full of records nobody can explain.