Privacy, ethics, and auditability

The UK GDPR (retained EU GDPR under UK domestic law via the European Union Withdrawal Act 2018, enforced by the ICO) applies to any processing of personal data about UK data subjects regardless of where the controller is located. Article 5 defines seven principles governing all personal data processing:

1. Lawfulness, fairness, and transparency (5(1)(a)): processing must have a lawful basis; data subjects must be informed.
2. Purpose limitation (5(1)(b)): data collected for one purpose may not be repurposed without a fresh legal basis.
3. Data minimisation (5(1)(c)): collect only what is adequate and necessary for the stated purpose.
4. Accuracy (5(1)(d)): personal data must be accurate and kept up to date.
5. Storage limitation (5(1)(e)): data retained no longer than necessary for the purpose.
6. Integrity and confidentiality (5(1)(f)): appropriate technical and organisational security measures required against unauthorised or unlawful processing, accidental loss, destruction, or damage.
7. Accountability (5(2)): the controller must be able to demonstrate compliance with all other principles.

Article 25 specifies what "appropriate" means in design terms: data protection measures must be implemented at the time of system design, not retrofitted. This is privacy by design. Privacy by default means protective settings are the default state; users must opt in to additional data collection rather than opting out.

The seven Article 5 principles are stable, but the law around them moved in 2025. The Data (Use and Access) Act 2025 (DUAA), which received Royal Assent in June 2025, changes several specific mechanisms in the UK regime without rewriting those principles. The changes matter to a security or engineering team because each one shifts an assumption a system may have been built on, and the ICO is publishing updated guidance on them through 2026, so the safe working assumption is that the pre-2025 position no longer holds until you have checked it.

The most concrete change is a seventh lawful basis. Alongside the six classic Article 6 bases, DUAA adds recognised legitimate interests: five defined public-interest purposes a controller may rely on without carrying out the legitimate-interests balancing test. The full set of bases is taught in the foundations privacy and data protection module; here the point is operational. A lawful-basis register that listed six options is now a seven-row table, and any processing that had been squeezed into ordinary legitimate interests should be re-checked against the new basis rather than assumed to need the same balancing exercise.

Three further mechanisms changed at the same time. DUAA altered how subject access requests operate, so the handling process a 2024 playbook assumed may no longer hold in every detail. It changed the rules on solely automated decision-making, decisions taken about a person with no meaningful human involvement, which bears directly on any team running scoring, triage or filtering models. And it revised the consent position for some categories of cookies and similar device storage. None of the three is a free pass: each moves where the line sits. All of the Act's data protection provisions are now in force, the last of them on 19 June 2026, and the ICO guidance is published, so the engineering response is to re-baseline the affected controls against the current position rather than assume either the pre-2025 rules or the most permissive reading of the new ones.

The reform also lands on how AI systems are built. Training a model on records about people, or pointing a retrieval corpus at them so an assistant can read them at query time, is processing of personal data in exactly the sense Article 5 means. Each of those data flows needs a lawful basis chosen in advance, a retention position, and a route for data subjects to exercise their rights, the same as any other processing activity. The controls that keep those AI data flows safe, from prompt injection through to excessive agency, are the subject of the AI security module; the point to carry from here is that the model pipeline is not a technical exception to data protection law. It is one more system that has to name its lawful basis before it processes a single record.

PETs are technical controls that minimise personal data use or protect it in ways that enable useful processing while reducing privacy risk. They implement privacy by design at the technical layer.

• Pseudonymisation: replace identifiers with pseudonyms; store the mapping separately. Enables analytics without direct identification; data remains personal data under UK GDPR.
• Anonymisation (k-anonymity, l-diversity): remove or generalise data until re-identification is not feasible. Anonymised data falls outside UK GDPR. Suitable for releasing aggregate research datasets.
• Differential privacy: add calibrated statistical noise to query results. Used for publishing statistics without revealing individual records (used by UK Census 2021).
• Homomorphic encryption: compute on encrypted data without decrypting. Enables cloud analytics on sensitive data.
• Tokenisation: replace sensitive values (payment card numbers, national insurance numbers) with non-reversible tokens. PCI DSS requires tokenisation or encryption for cardholder data at rest.

The UK NHS COVID-19 contact tracing app (2020) used a decentralised architecture as a privacy by design choice: proximity detection exchanged anonymous random identifiers via Bluetooth Low Energy; matches were computed on the user's own device. The NHS never received a list of who had been in proximity to whom. The privacy trade-off was explicitly documented: lower epidemiological data utility in exchange for stronger privacy guarantees and higher voluntary adoption.

The Computer Misuse Act 1990 is the primary UK legislation criminalising unauthorised computer access. Three main offences: Section 1 (unauthorised access to computer material), Section 2 (unauthorised access with intent to commit further offences), and Section 3 (unauthorised acts with intent to impair). The word "unauthorised" is critical. Security testing performed with explicit written authorisation from the system owner is not an offence.

Lawful penetration testing requires: a scope agreement in writing specifying which systems, IP ranges, and test types are authorised; time-bounded authorisation; rules of engagement; and separate consideration of third-party services. Authorisation from the target system's owner does not extend to third-party SaaS platforms, cloud providers, or payment processors that share infrastructure. Bug bounty scope boundaries are legally binding: a researcher who tests systems outside a stated scope may be prosecuted under the Computer Misuse Act even if they find a genuine vulnerability and report it responsibly.

A well-designed bug bounty programme includes: clear written scope with explicit in-scope and out-of-scope asset lists; safe harbour language stating the organisation will not pursue legal action against researchers acting within scope and in good faith; a reward structure with minimum and maximum bounty amounts per severity tier; a response SLA (triage within X days, status update within Y days, payment within Z days of patch release); and an acknowledgement policy. Responsible disclosure (coordinated vulnerability disclosure) allows researchers to set a disclosure deadline (typically 90 days as per Google Project Zero policy) after which details are published regardless of patch status.