Data Protection Officer

In a company where nobody owns personal data, the question never comes up until something breaks. Whoever builds the signup screen decides which fields to ask for. Whoever writes the storage layer decides where those values live and how long they stay. Whoever runs the mailing list decides what to send to them. Each person knows their own piece exactly, and no one holds the whole picture.

The gap usually surfaces on the day of an incident. Someone looks at a file that left the building, sees dates of birth in it, and asks why the company had them. Engineering says marketing asked for the field. Marketing says the plan was to split emails by age group and it never happened. Nobody can say when collection started or how many records exist right now. Meanwhile the clock on the regulator's reporting deadline keeps running.

Regulation closed that gap with a named person. Above a certain size, a company has to appoint someone to oversee personal data and publish that person's title and contact details in its privacy policy — the public document stating what gets collected, what it is used for, and when it gets deleted. Once a name sits there, outsiders have somewhere to write to, and insiders know who to ask.

The day fills up with requests arriving from outside and reviews coming up from inside. Five kinds of work dominate.

1. Handling data subject requests. People write in asking what the company holds about them, or asking for all of it to be deleted. The response deadline is set by law, usually measured in days. The hard part is that one person's data is never only in the user database — it is also in payment records, support tickets, and analytics tools. Without a standing inventory of what sits where, the deadline is unreachable.
2. Maintaining that inventory. Every field gets a row: why it is collected, where it is stored, how long it is kept. Each new feature that adds a field adds a row, which is why the inventory only stays accurate if it is updated as features ship.
3. Reviewing new features. Before a design is final, the question is whether each field is genuinely needed and what legal basis covers collecting it. The most common basis is consent, which requires telling people what the data is for and letting them actively agree. The fields that stall here are the ones that look nice to have and feed no actual feature.
4. Incident response. Once a leak is confirmed, the regulator gets notified and the affected people get told, both inside a fixed window. Working out who to call on the day of the incident guarantees missing the window, so the sequence is written down in advance.
5. Audits and training. Each quarter, pull the list of who can reach which data and revoke what is no longer needed. Telling staff not to export customer data into personal accounts comes from this desk too.

Almost nothing here gets decided alone. The work mostly takes the form of attaching conditions to someone else's decision, and five groups are on the other side of it.

1. Engineers. They know which values live where, so every access or deletion request gets worked through with them. When the product has no way to delete something, this is who gets asked to build one.
2. Product managers. Arriving after a feature is built means redrawing screens, so the conversation happens during design. Cutting a field costs almost nothing at that point and a great deal later.
3. Sales and customer success. Enterprise security questionnaires arrive with personal data sections, and so do the contracts covering data processed on a customer's behalf.
4. In-house counsel. Turning a review into contract language belongs to the legal side, and at a small company one person often holds both jobs.
5. Security and compliance. The work sits on top of the security governance that a chief information security officer (CISO) owns — the documented rules for access and procedure and the checks that they are followed. A compliance manager folds personal data items into quarterly reviews, and security certification work pulls this role in as well.

"Let's get this field past the data protection officer before we ship it. Do we have a reason to ask for date of birth?"

A proposal to cut collected fields while the design is still cheap to change.

"A deletion request came in yesterday and the analytics data still isn't gone."

The deadline is running and one system has no way to comply.

"A customer wants the data processing agreement. Is the contact in the privacy policy still current?"

Checking that what is published externally matches reality.

At Pagedeck, Grace is the appointed DPO, and Theo and Sofia split the hands-on work. With forty-five people, dedicating someone full time isn't realistic, so this split is the common arrangement. As enterprise deals grew, questionnaires started arriving with sections on where data is stored and who can read it, and Grace is the one who assembles the answers.

Mia routes new features through the same desk. When someone proposed showing who opened a document and when, the retention period for those logs and how long a departed employee's name stays visible were settled before any screen got drawn.

The most common misreading treats this as a paperwork job. The visible output is updated documents and filings, which makes it look distant from the product. But the decisions that actually matter live inside the product: which fields to collect, what happens to records when an account is deleted, how many months of access logs to keep. Those are screen and schema decisions. Keep the role on the documentation side and it hears about them only after they are made, when fixing anything means tearing out work that already shipped.

The other mistake is assuming the appointment itself is the deliverable. The law asks for a named, published person, so it reads that way. But the moment the name goes up, that person carries the consequences of an incident. That is why the appointment avoids anyone who would end up reviewing their own work — put the head of the department that uses data most into the role and there is nobody left to argue for collecting less. An appointment made without authority or time produces reviews that exist on paper only, and an investigation shows that clearly.