Recognised Legitimate Interests Under DUAA: A Data-Protection Engineering Checklist

Lawful basis is not a policy statement. It is a value stored against records, enforced by your systems, and inspected when something goes wrong. The DUAA has added a new one, and if your data model cannot hold it, your paperwork saying otherwise will not help you.

The Data (Use and Access) Act 2025 introduced a category the UK GDPR did not previously have: recognised legitimate interests. It sits alongside the familiar six lawful bases in a new Article 6(1)(ea), with the qualifying purposes set out in a new Annex 1. The data-protection provisions carrying it commenced on 5 February 2026, so this is live, not forthcoming. Most of the commentary treats it as a legal question. It is not. It is a change to the enum in your lawful-basis field, the branching in your consent capture, and the tags on every record you already hold. This is the engineering checklist for that.

What actually changed, in system terms

Ordinary legitimate interests under Article 6(1)(f) require a balancing test: you weigh your interest against the rights of the people whose data you are using, and you document that assessment as a legitimate interests assessment. Recognised legitimate interests remove the balancing test. If your processing falls within one of the Annex 1 purposes and is necessary for it, you have a lawful basis without producing an LIA.

The Annex 1 list is narrow and deliberately so. As enacted it covers five purposes:

1. Disclosing personal data to a public body that has stated it needs the data to carry out a public task.
2. Safeguarding national security, protecting public security, and defence.
3. Responding to an emergency.
4. Detecting, investigating or preventing crime.
5. Safeguarding vulnerable individuals.

The Secretary of State can add to this list by secondary legislation, so treat Annex 1 as a versioned reference in your codebase, not a constant you hard-code once and forget. The single most common mistake you can make here is to read “no balancing test” as “easier basis” and start re-mapping ordinary commercial processing onto it. It does not reach marketing, product analytics, or intra-group data sharing for business purposes. Those stay on Article 6(1)(f) with an LIA, or on consent. Recognised legitimate interests are for the public-interest, crime, safeguarding and emergency cases and nothing else.

Model the basis against the purpose, not the record

The structural error I see most often is a lawful-basis column stamped directly onto each personal-data record. It goes stale the moment a record is reused for a second purpose, and it cannot represent the same person’s data being processed for two purposes under two different bases. Lawful basis is a property of the processing purpose. Records reference a purpose; the purpose carries the basis. Get that relationship right and the DUAA change is a small extension rather than a migration.

-- Lawful basis modelled against the processing purpose, not the record.
-- Records reference a processing_purpose; the purpose carries the basis.

CREATE TYPE lawful_basis AS ENUM (
  'consent',                          -- Art 6(1)(a)
  'contract',                         -- Art 6(1)(b)
  'legal_obligation',                 -- Art 6(1)(c)
  'vital_interests',                  -- Art 6(1)(d)
  'public_task',                      -- Art 6(1)(e)
  'legitimate_interests',             -- Art 6(1)(f)  -- requires an LIA
  'recognised_legitimate_interests'   -- Art 6(1)(ea) -- DUAA, no balancing test
);

-- Annex 1 sub-grounds; valid only when basis = recognised_legitimate_interests.
CREATE TYPE rli_ground AS ENUM (
  'public_body_disclosure',
  'national_public_security_defence',
  'emergency_response',
  'crime_detection_prevention',
  'safeguarding_vulnerable'
);

CREATE TABLE processing_purpose (
  id                text PRIMARY KEY,
  name              text NOT NULL,
  basis             lawful_basis NOT NULL,
  rli_ground        rli_ground,        -- required iff basis is recognised_...
  necessity_note    text NOT NULL,     -- why processing is necessary for this purpose
  lia_reference     text,              -- LIA document id; required iff basis is 6(1)(f)
  objection_applies boolean NOT NULL DEFAULT true,
  retention_days    integer NOT NULL,
  reviewed_on       date NOT NULL,
  -- A recognised-LI purpose carries a sub-ground and no LIA; ordinary LI is the reverse.
  CONSTRAINT rli_requires_ground CHECK (
    (basis = 'recognised_legitimate_interests') = (rli_ground IS NOT NULL)
  ),
  CONSTRAINT li_requires_lia CHECK (
    basis <> 'legitimate_interests' OR lia_reference IS NOT NULL
  )
);

The two check constraints are the point. They make the schema refuse a recognised-legitimate-interests purpose that has not named its Annex 1 ground, and refuse an ordinary legitimate-interests purpose that has no LIA on file. The database, not a reviewer’s memory, enforces the distinction the DUAA drew.

Rework the consent plumbing, carefully

Some firms have been leaning on consent, or on a stretched legitimate-interests argument, for exactly the disclosures Annex 1 now covers: passing data to a public body on request, sharing for a safeguarding concern, responding to an emergency. Where that is the case, you can re-base those flows onto recognised legitimate interests and stop collecting a consent you never really needed. The gain is real: a consent you relied on could be withdrawn, which meant the lawful basis for a legitimate public-interest disclosure could evaporate on a data subject’s whim.

Do it deliberately. Re-basing means your consent capture must stop writing a consent record for that purpose and start writing a necessity note against the correct Annex 1 ground. It also means the withdrawal and preference screens must no longer offer to switch off a purpose that is not, in fact, consent-driven any more, or you will mislead people and create support tickets you cannot honour. This is the same discipline that a serious consent re-engineering programme demands: the UI, the stored basis, and the withdrawal logic have to tell one story. And recognised legitimate interests do not switch off transparency or the other principles. People still have to be told, and the right to object still bites where it applies, so keep the objection flag and honour it.

The purpose-compatibility change you will miss

Recognised legitimate interests get the headlines, but the DUAA also revised how further processing is judged compatible with the original purpose. It sets out a list of situations treated as compatible, so that reuse for those purposes does not need a fresh compatibility assessment. If your pipeline has a “further processing” gate that runs a compatibility check before allowing reuse, that gate now needs to know which reuses are pre-cleared and which still require the full assessment. Store the compatibility determination as data against the purpose, with the reason, rather than leaving it as a judgement someone made once in a document nobody reads. The wider shape of the Data (Use and Access) Act rewards teams that treat these as data-model changes.

The ordered set of changes

1. Add the seventh value to your lawful-basis enum and a controlled sub-ground field for Annex 1. Version Annex 1 so a new ground added by the Secretary of State is a data change, not a schema migration.
2. Make the LIA-required and ground-required rules structural constraints, not review guidance.
3. Inventory current processing and identify only the qualifying public-interest, crime, safeguarding and emergency flows. Re-base those; leave everything else where it is.
4. Update consent capture and withdrawal screens so re-based purposes no longer present as consent, and back-fill necessity notes.
5. Encode the new purpose-compatibility positions in your further-processing gate.
6. Regenerate your record of processing activities from the model, so the register and the running system agree.

The same registry that answers a supervisor’s lawful-basis question is the one that answers a data subject’s, which is why the teams doing this well are also the ones rebuilding their DSAR and complaints tooling off the same model, and re-examining their automated decision-making safeguards at the same time. Do the record-level work now. When the regulator asks which basis you relied on to disclose a person’s data, “recognised legitimate interests, this Annex 1 ground, this necessity note, on this date” is an answer. A policy PDF is not.