What Does a Privacy Team Do?

A privacy team's mission is to treat people's data in line with their expectations¹.

Expectations like:

• When I upload a picture to Google, I control who sees it
• When I ask to delete my data, that happens

There are expectations about how people's data should be treated. Some become law². Some are company policy or explicit promises. Either way, nobody hands you GDPR and says, 'Go implement Chapter 3’ somebody has to turn them into precise rules that you can then write code to satisfy.

Take GDPR Article 17, the right to erasure:

Article 17 requires deletion without undue delay when one of its grounds applies, such as when personal data is no longer needed for its original purpose. It also sets out exceptions, including certain legal obligations and legal claims.

This is a legal standard that needs more detail before engineers can implement it. To engineer-folks it’s “underspecified” so we can’t go build software from it without some detail-enhancing questions first.

We might define the following:

• Scope: "personal data" includes any text, email, photo, or data derived about a user.
• Retention: user data is deleted within 30 days of account deletion.
• Coverage: deletion happens everywhere the data lives — every storage system and backup.
• Assurance: at least 99.99% of eligible deletion requests complete across all systems in scope by the deadline. Every missed deadline is detected and investigated.

The process of adding detail forces companies to decide important aspects of how they comply with the law:

• Which data must be deleted?
• Which data must we retain, and why?
• How do we handle backups?
• How do we stop a restored backup from bringing deleted data back?

The output of the interpret stage is a requirement. The requirement is a clear, specific, actionable answer to “what exactly should happen (to comply with this law)”.

Once you know what the requirements are, you have to make them true.

A control is a system or process that makes a requirement hold. For deletion, that might be a service that finds and removes a user’s data.

The privacy team may build shared tools and services. Product and infrastructure teams often do much of the implementation. The privacy team helps define the requirements and checks that the combined system meets them.

That happens via:

• Building reusable privacy controls.
• Deploying them consistently across products
• Detecting when those controls drift or fail.

Building a privacy control can take months or years. Deploying them consistently is an intense, neverending process for any company that ships a lot of products.

Our controls for this deletion requirement might be:

1. Scope - a classifier / data catalog that tags which stored objects are user data.
2. Coverage - a data inventory of every storage system and backup holding user data — you can't delete everywhere until you know everywhere.
3. Retention — a deletion pipeline that removes tagged data across all inventoried systems before the 30-day deadline.
4. Assurance - monitoring that measures deletion success and alerts when it drops below target.

At scale, the hard part is often achieving and maintaining coverage: making sure the controls apply to every relevant product and system.

A deletion pipeline can work correctly and still fail the user. A product team adds a search index, cache, or analytics store but does not connect it to deletion.

There are lots of ways to find where a control should be hooked up. The best are programmatic: for example, scan the code for writes to a storage system and check that it supports deletion. The big catch-all is a company-wide launch gate, which the privacy team often operates.

The output of this stage is a bunch of controls that uphold the requirement.

The last part of the job is proving that everything above actually worked.

A green dashboard only tells you about the systems it measures. To support a deletion claim, we need evidence that deletion worked and that we checked the right places.

That proof has two audiences.

1. Internal assurance. We need to find failures and fix them.
2. External evidence. We need to explain to regulators, auditors, and customers what we checked, what we found, and why the evidence supports our claim.

For this deletion requirement, that looks like:

Internal:

• Test - Seed test accounts with photos, delete them, and assert the data is gone from every inventoried system and backup — not just the primary store.
• Monitor - Track the deletion success rate against the stated target; page when it drops.
• Alert when the inventory goes stale, e.g. a new storage system ships without being registered for deletion.

External:

• A dashboard showing deletion volume and success rate over time, backed by immutable logs an auditor can inspect.
• A documented retention policy and implementation record explaining the retention decision, the systems in scope, and how deletion is enforced and monitored.
• Per-request deletion receipts: for a given user and date, evidence that their data was deleted everywhere by the deadline.

One thing I didn't appreciate before doing this job is that the need to prove something often changes how you build it.

A deletion service must do more than accept a request. It must track completion across downstream systems and expose failures. If you add those features during design, evidence becomes an output of the system.

Proving compliance becomes a software design problem.