Beyond legal #8: Why your next hire should be a data protection engineer

The next competence I’m recommending in my ‘beyond series’ is obvious and unavoidable. It’s data protection engineering. Not as another tickbox, but as the pragmatic and knowledgeable facilitator that turns legal requirements and governance decisions into meaningful solutions that people can actually use and trust. This is especially relevant in companies where data protection is treated as administration rather than design.

Why data protection engineering, and why now?
As I have harped on about so many times over the years, too many companies treat data protection as a legal issue you solve with paperwork. That dominant mindset unfortunately manifests in many painfully familiar scenarios: opaque, long-winded privacy notices no one reads, clunky cookie consent mechanisms that frustrate users, and template-driven DPIAs and RoPAs that align with supervisory authority guidelines but are often ineffective and are off no practical use, to name a few examples. These “legal solutions” create theatre. Loads of documents, lots of generic education but very little real reduction in risk.

Instead of asking “are we compliant and how do we prove it?” you might want to flip that question to: “how do we build products that behave correctly from the start?” It’s all about getting things right up front, from the outset, rather than doing the bare minimum and then trying to fix things afterwards.

Why now? In the past few months I have participated in a few client meetings where the key challenge has been around retrospectively fixing existing business solutions that had zero data protection considerations from the outset. Data protection professionals were not part of the original solution design process aside from a few last minutes reminders - remember the privacy notice, remember to add the solution to the RoPA, update the DSAR intake registry, etc. All after thoughts.

It’s also timely because there’s a general perception that data protection is, on the whole, ‘difficult’ and complex to navigate. I’m not suggesting a data protection engineer will transform things overnight, but a positive effect will be realised if you gather the right people who are qualified to operationalise the often, abstract legal requirements.

There is also ‘privacy engineering’ which I believe originated in the US. I know NIST has huge resources about the discipline and it seems we’re playing catch-up slightly in Europe, but ENISA publish a good guide a few years back, and a preliminary opinion by the EDPS is also worth a read. In my own network I know a few good privacy and data protection engineers that work outside of bigtech and these seem to be primarily located in Belgium and the Netherlands for some reason. To get a full understanding, I can only recommend you take a look at both NIST and ENISA's material as it contains a wealth of information. What I particularly like about NIST's approach is it's alignment with quality - a term we rarely hear much about in data protection currently. Also, and on a high level, NIST places focus on three primary engineering objectives:

Predictability: The capability for individuals and system operators to reliably understand how personal data will be processed by a system, so that the system's behaviour matches people’s expectations.

Manageability: The degree to which individuals and system operators can control or influence how personal data is processed, including allowing people to request access, rectification, or erasure of data about themselves as appropriate.

Disassociability: The ability for personal data to be processed in a way that limits unnecessary association with individuals, allowing data to be used, shared, or analysed without routinely linking back to identities unless necessary.

I really think these are worthy objectives, which unfortunately are not yet fulfilled by many companies currently. A quick and short question to you if you are a data protection leader: Hand on heart, how close are you to focusing on similar objectives in your data protection practice?

I see a data protection engineer as a multi-disciplinary facilitator that can comfortably sit between colleagues from legal, product, UX, software engineering, EA and security, and translate legal requirements into architecture, design and operational controls that actually work at scale.

Despite everything I write in this ‘beyond legal’ series I also want to repeat again, that legal teams are indispensable in data protection. They understand and interpret applicable laws and regulations, explain them to the rest of us in business terms, establish and manage the legal risk framework among many things. But legal alone can’t design solutions needed to implement retention and deletion requirements in legacy systems, or embed pseudonymisation into a data model, or embed data protection considerations in a product’s UX so it’s usable instead of threatening.

In my world, ’unity’ is realised when a collection of the needed competences regularly work together at different times depending on the context, risk and difficulty of what’s needed. So, legal, business tech and data protection engineering should work as equal partners in say solutioning an intrusive piece of martech to be deployed across multiple jurisdictions. Legal explains the “what,” engineering designs the “how,” and business tech or product makes the “how” part of the user experience.

So, data protection engineers certainly can be a great help, but unfortunately there is not an abundance of people with such competences on the job market at the moment. They are a rare talent these days.

Common areas where they can add value
Data protection engineering is not about drafting longer notices or inventing more wonky compliance artefacts. It’s about making data protection a quality attribute of a product or service, helping translate risk into technical trade-offs. On a more technical level, an engineer brings these skills and knowledge areas to a data protection team:

• Turns DPIA and risk outputs into engineering requirements and acceptance criteria that developers can implement and test.

• Threat-models features early to find data protection and privacy risks in data flows, business logic and edge cases.

• Designs architectures that minimise data collection, isolate sensitive data, and make deletion and retention possible.

• Builds developer libraries, CI/CD (continuous integration and continuous delivery/deployment) checks and policy-as-code that make data protection as the default path in development workflows.

• Designs usable transparency and control interfaces so people can make meaningful choices without being bullied or shamed.

• Provides monitoring and remediation tooling so you can detect misuse, investigate quickly, and fix systemic causes rather than paper over incidents (have you ever done that?).

• Participate in incident response and forensics that leads to systemic change, not just legal notifications.

As I have done in all my earlier posts, I want to anchor competences using the SFIA skills matrix but unfortunately ‘data protection engineering’ does not (yet?) feature in the framework. I’m not sure whether it’s a US v UK thing because SFIA originates in Britain. If you recognise the shortcomings in your data protection work and you’re building capability, the following skills are relevant and map to the SFIA framework so you can use this as a guide as to who to engage with, recruit or develop:

• Systems design (DESN) - translate outputs from DPIAs and other risk assessments into modular, testable architecture.

• Information security (SCTY) - design encryption, key management and access models aligned to data protection requirements and risks.

• Infrastructure design (IFDN) and Infrastructure operations (ITOP) - ensure consistent controls across cloud/on-prem/hybrid.

• Requirements definition & management (REQM) - turn DPIA outputs into clear acceptance criteria for backlogs.

• Programming / software development (PROG) - implement privacy-preserving patterns and libraries.

• Deployment (DEPL) and Release Management (RELM) - embed privacy gates into CI/CD and automate runtime enforcement.

• User experience analysis (UNAN) - design and develop usable and meaningful user interfaces and control flows that actually work and avoid dark patterns

• Data management (DATM) - design lifecycle, minimisation and retention enforcement into schemas and flows.

• Data science (DTSD) - apply anonymisation and statistical reasoning to safe analytics.

• Quality assurance (QUAS) and Audit (AUDT) - provide technical evidence of implemented controls.

• Learning & development (TMCR) - develop and run contextual education, training and awareness.

• Safety assessment (SFAS) and Safety engineering (SFEN) - especially relevant for AI product safety

• Threat modelling (THIN) - a proactive process to identify and address potential data protection risks and violations within a system or application. Note: this competence does not appear in the base SFIA framework, but I have seen it in some frameworks that have been adapted by specific sectors.

As I mentioned earlier in the post, I see data protection engineers as facilitators. They’ll reduce friction for product teams by offering workable, low-friction technical solutions and by translating legal constraints into (sometimes) innovative alternatives. They’ll prototype lower-risk options, embed data protection into developer workflows, and make it easy for teams to do the right thing, rather than force them to implement clunky and wonky compromises.

The result? If allocated correctly their involvement will reduce the need for last minute legal rewrites, lower rework costs, and most importantly, reduces the likelihood of real-world harm.

Purpose and Means is a niche data protection and GRC consultancy based in Copenhagen but operating globally. We work with global corporations providing services with flexibility and a slightly different approach to the larger consultancies. We have the agility to adjust and change as your plans change. Take a look at some of our client cases to get sense of what we do.

We are experienced in working with data protection leaders and their teams in addressing troubled projects, programmes and functions. Feel free to book a call if you wish to hear more about how we can help you improve your work.