Last updated: 2026-09-26

U
Undergraduate level

Data Protection Law and Ethics

Professional 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 Ephemeral / ToolingKnowledge that evolves in months to a year — check for updates

UK 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 framework1. The Act itself runs to hundreds of sections, but a handful of requirements recur constantly in ordinary system design:

Lawful Basis for Processing Ephemeral / ToolingKnowledge that evolves in months to a year — check for updates

Personal 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.consent is only one of six lawful bases

Data Minimisation Ephemeral / ToolingKnowledge that evolves in months to a year — check for updates

Collect 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.

Don't do this! Don't collect a field of personal data "in case it's useful later" — the lawful basis for collecting it has to already exist, not be deferred to a hypothetical future feature.

The Right to Erasure Ephemeral / ToolingKnowledge that evolves in months to a year — check for updates

An 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.an immutable ledger makes this awkward

Note well. Personal data replicated across backups, caches, logs, and third-party analytics services all need a genuine deletion path, not just the primary production database.

Breach Notification Ephemeral / ToolingKnowledge that evolves in months to a year — check for updates

A 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 Applied / MethodologicalKnowledge with a 5–10 year half-life — stable practice

Each 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.

  • Professional Ethics — the general frameworks this page already narrows into concrete data-protection requirements; worth reading for the wider professional obligations those requirements sit inside.
  • Legal Framework in Computing — the broader UK legal landscape (GDPR's full structure, the Computer Misuse Act, cross-border transfer rules) that this page's design-decision focus is one narrow slice of.
  • Unix Permissions — the concrete access-control mechanism that actually enforces "only authorised parties can read this data" once the legal requirement has been identified.
  • Blockchain Fundamentals — a blockchain's immutability guarantee is in direct tension with the right to erasure covered here, a real architectural collision between two design goals.

References

  1. Data Protection Act 2018, c. 12. https://www.legislation.gov.uk/ukpga/2018/12/contents ↩