Data Protection Law and Ethics

ProfessionalProfessional Ethics covers the general frameworks — deontological, virtue-based, utilitarian — for reasoning about a professional dilemma. This page is narrower and more concrete: what UK and EU data protection law actually requires of a system that stores personal data, translated from legal language into design decisions a developer has to make.

UK GDPR and the Data Protection Act 2018

UKUK GDPR (the retained, UK-specific version of the EU's General Data Protection Regulation, following Brexit) and the Data Protection Act 2018 together form the current legal framework¹. The Act itself runs to hundreds of sections, but a handful of requirements recur constantly in ordinary system design:

Lawful Basis for Processing

PersonalPersonal data can't simply be collected because it might be useful — every instance of processing needs an identified lawful basis before it happens: consent, a contractual necessity, a legal obligation, protecting someone's vital interests, a task in the public interest, or a legitimate interest balanced against the individual's rights. In practice, this means a system's design has to be able to answer, for every field of personal data it stores, why it's allowed to store that field at all — not just that it's technically convenient to have it.

Data Minimisation

CollectCollect only what's genuinely needed for the stated purpose, not everything that might conceivably be useful someday. This is a direct, concrete design constraint on a database schema: a registration form asking for a date of birth "in case it's useful later" is a minimisation violation if nothing in the system actually uses it yet — the lawful basis for collecting a field has to already exist, not be deferred to a hypothetical future feature.

The Right to Erasure

AnAn individual can request that their personal data be deleted, and — outside specific exceptions (a legal retention obligation, for instance) — the system has to actually be able to do that. This has real architectural consequences that are easy to overlook until the request actually arrives: personal data replicated across backups, caches, logs, and third-party analytics services all need a genuine deletion path, not just the primary production database. A system that logs a user's email address into a plain-text log file with no retention policy has quietly created a copy of personal data that "delete my account" doesn't reach.

Breach Notification

AA personal data breach likely to result in risk to individuals has to be reported to the Information Commissioner's Office within 72 hours of the organisation becoming aware of it, and communicated directly to affected individuals if the risk is high. The practical design consequence: a system needs the ability to actually detect a breach and determine its scope quickly — which specific records were exposed, not just "some records, we're not sure how many" — because the 72-hour clock starts running regardless of whether the system was built with the logging and auditing needed to answer that question fast.

From Law to Design

EachEach requirement above maps onto a concrete, checkable design decision, not just a policy document: lawful basis maps onto documenting, per data field, why it's collected; data minimisation maps onto a schema review asking whether each column is actually used; the right to erasure maps onto an audit of every place personal data is copied to, not just where it's canonically stored; breach notification maps onto having enough logging and monitoring in place, before an incident happens, to answer "what exactly was exposed" quickly rather than needing to reconstruct it under pressure. Treating data protection as a set of engineering requirements to design against from the start is considerably cheaper than retrofitting compliance onto a system after it's already collecting more than it needs and can't account for where it all ends up.

References