FAQ item index

Search every question across sub-FAQs

Find the exact question, open the source answer card, and copy a direct link to the anchored sub-FAQ response.

Indexed coverage
33of33items
Across 11 modules • Updated Jul 27, 2026
Author
Sorena AI
Published
May 9, 2026
Updated
Jul 27, 2026
How do you choose a lawful basis under the UK GDPR?

How should a controller choose among the seven bases?

Start with the purpose, the controller's relationship with the person, and the legal or practical reason the processing is needed. Contract applies only where processing is objectively necessary to perform a contract with the person or take requested pre-contract steps. Legal obligation needs a duty imposed by UK law. Vital interests is narrow and protects a person's life. Public task requires a task in the public interest or official authority laid down by law.

Use consent only when the person has a genuine choice and can withdraw without detriment. Use ordinary legitimate interests only after the purpose, necessity, and balancing tests. Use recognised legitimate interest only when every requirement of a specific Annex 1 condition is met; unlike ordinary legitimate interests, it does not require a separate balancing test.

  • Describe each purpose precisely. One system may need different bases for account delivery, fraud prevention, analytics, and marketing.
  • Test necessity: if a less intrusive reasonable method achieves the purpose, a necessity-based basis may not fit.
  • Do not treat contract terms or a privacy notice as proof that processing is necessary for a contract or legal obligation.
  • Tell people the lawful basis and purpose in the privacy information, subject to any applicable exception.
Citations
ICO - A guide to lawful basis

Explains when each Article 6 basis may apply, the need to choose before processing, necessity, documentation, and privacy information.

How do you choose a lawful basis under the UK GDPR?

What additional checks are required?

Article 6 is only the first layer. Processing special category data also needs an Article 9 condition. Processing criminal offence data must satisfy Article 10 and usually a condition in the Data Protection Act 2018. If the activity uses cookies or similar storage and access technologies, PECR may require consent even where another UK GDPR basis might otherwise appear available.

The selected basis also changes the rights analysis. For example, the right to data portability is tied to consent or contract and automated processing, while the right to object is particularly relevant to public task and legitimate interests. No lawful basis overrides fairness, transparency, purpose limitation, data minimisation, accuracy, storage limitation, security, or accountability.

  • Record any Article 9 condition, Data Protection Act 2018 Schedule 1 condition, or Article 10 authority separately from the Article 6 basis.
  • Check PECR before the UK GDPR when storing information on or accessing information from a user's device.
  • Assess children's reasonable expectations and interests with extra care, especially under legitimate interests.
  • Complete a DPIA where the proposed processing is likely to result in a high risk to people's rights and freedoms.
Citations
ICO - Special category data

Explains that special category processing needs both an Article 6 lawful basis and an Article 9 condition, with further DPA 2018 requirements for some conditions.

How do you choose a lawful basis under the UK GDPR?

What evidence should the controller keep?

Keep a decision record that identifies the controller, data and people affected, each purpose, the chosen basis, the facts supporting it, the necessity analysis, and the approval date. Add the relevant contract clause, legal provision, consent record, public-task authority, Annex 1 condition, or legitimate interests assessment rather than relying on a label alone.

Update the record and privacy information when the purpose or processing changes. A controller should not switch basis after processing has started merely because the original choice became inconvenient. A genuine change in circumstances may justify a different basis, but the controller must document the change, assess fairness, and tell people where required.

  • Map every processing purpose in the record of processing activities to its Article 6 basis.
  • For consent, retain what the person saw, the affirmative action, the time, the scope, and any withdrawal.
  • For recognised legitimate interest, name the Annex 1 condition and show how every element and the necessity test are met.
  • For legitimate interests, retain the purpose, necessity, and balancing assessment and the safeguards adopted.
Citations
UK Children's Code: Scope and 15 Standards

Does the Children's Code apply to our service?

Check whether the service is an information society service: a service normally provided for remuneration, at a distance, by electronic means, at the individual request of a recipient. Most for-profit online services meet that definition. Then assess whether the service is likely to be accessed by children under 18 in the UK, not merely whether the product is marketed to them.

Use evidence about the nature and presentation of the service, appeal to children, actual audience, comparable services, marketing, user research, and the effectiveness of access restrictions. If the service is unsuitable for children and reliable controls prevent their access, document that conclusion. If evidence later shows a substantive child audience, revisit the assessment and either conform to the code or improve the restriction.

The statutory scope excludes a general broadcast that is not provided at an individual's request and a preventive or counselling service, such as an online health screening or counselling service, offered specifically to children. An on-demand element of a broader broadcast and a general health, fitness, or well-being service can still be covered. The code came into force on 2 September 2020, and its 12-month transition ended on 2 September 2021, so an in-scope service should conform now.

  • Map UK child users, age ranges, personal data, profiling, sharing, geolocation, default settings, nudges, and parental features.
  • Document the evidence for likely access and review it after product, audience, marketing, or access-control changes.
  • Apply the code's territorial rules carefully. It covers processing in the context of a UK establishment and can cover a provider outside the UK that offers services to, or monitors, people in the UK. Since the end of the EU exit implementation period, this includes a provider with no UK establishment but an establishment elsewhere in the EEA.
  • Keep the Article 8 consent rule distinct from the code's under-18 design scope. For an information society service relying on consent, a UK child can give their own consent from age 13; below 13, the holder of parental responsibility must give or authorise it. Another lawful basis may fit the processing, but the code can still apply to users up to age 18.
Citations
UK Children's Code: Scope and 15 Standards

What do the 15 standards require teams to address?

Treat the child's best interests as a primary consideration and complete a DPIA that assesses differing ages, capacities, and risks. Apply the code in a risk-based and proportionate way, but do not use proportionality to remove the substance of a standard.

The 15 standards cover: best interests; DPIAs; age-appropriate application; transparency; detrimental use of data; policies and community standards; high-privacy default settings; data minimisation; data sharing; geolocation; parental controls; profiling; nudge techniques; connected toys and devices; and online tools that let children exercise rights or report concerns.

  • Use high-privacy defaults unless a compelling reason, tied to the child's best interests, supports another setting.
  • Collect and retain only the minimum personal data needed for each active element of the service.
  • Keep geolocation off by default and make location tracking obvious while active.
  • Do not use nudges that encourage children to provide unnecessary data or weaken privacy controls.
  • Explain data use in concise, prominent, age-appropriate language and provide child-accessible privacy tools.
Citations
ICO - Age appropriate design code

The statutory code and its 15 standards, including best interests, DPIA, defaults, minimisation, sharing, geolocation, profiling, nudges, and tools.

UK Children's Code: Scope and 15 Standards

What evidence should product teams keep?

Keep the scope and age-range assessment, child-focused DPIA, design decisions against all 15 standards, user research, notices, settings, age-assurance reasoning, testing, parental-control behaviour, profiling logic, sharing map, geolocation controls, retention, and rights routes. Evidence should match the released product on each supported platform.

Review after new features, material interface changes, new profiling or sharing, changed age-assurance methods, a shift in the child audience, complaints, incidents, or evidence that a control does not work as intended.

Citations
UK GDPR 72-Hour Breach Reporting: Decision Guide

When must a controller report a breach to the ICO?

A personal data breach is a security breach leading to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data. It covers confidentiality, integrity, and availability failures, not only theft or disclosure.

The controller must notify the ICO unless the breach is unlikely to result in a risk to people's rights and freedoms. If notification is required, it must be made without undue delay and, where feasible, within 72 hours after the controller becomes aware. A processor must notify its controller without undue delay after becoming aware; Article 33 does not give processors their own 72-hour ICO deadline, although the contract may set a shorter escalation period.

  • Record the controller's awareness time and the facts that made the breach reasonably certain.
  • Assess the type of harm, affected people, sensitivity and volume of data, ease of identification, likely consequences, and measures already protecting the data.
  • Notify the ICO when risk is possible; record a reasoned decision when the breach is unlikely to result in risk.
  • Do not confuse the lower ICO-notification risk threshold with the high-risk threshold for telling affected people.
Citations
UK GDPR 72-Hour Breach Reporting: Decision Guide

What must the ICO report and incident record contain?

The Article 33 report must, where possible, describe the nature of the breach, including the categories and approximate numbers of affected people and personal-data records; give the data protection officer's or other contact's details; describe likely consequences; and describe measures taken or proposed to address the breach and mitigate harm.

If all information is not available at once, provide it in phases without undue further delay. A report made after 72 hours must include reasons for the delay. Keep the submission, receipt, later updates, and decision trail with the incident record.

  • Timeline: discovery, escalation, awareness, containment, risk decisions, ICO report, updates, and individual communications.
  • Scope: systems, data categories, affected people and records, jurisdictions, processors, and recipients.
  • Assessment: likely consequences, likelihood and severity of harm, protective measures, residual risk, and decision-maker.
  • Response: containment, recovery, credential resets, communications, further investigation, lessons learned, and control changes.
Citations
UK GDPR 72-Hour Breach Reporting: Decision Guide

When must affected people be told?

Article 34 requires the controller to communicate the breach to affected people without undue delay when it is likely to result in a high risk to their rights and freedoms. The communication must use clear, plain language and include the contact point, likely consequences, and measures taken or proposed, including mitigation.

Direct communication is not required if appropriate measures made the data unintelligible to unauthorised people, later measures ensure the high risk is no longer likely to materialise, or direct contact would involve disproportionate effort. In the last case, the controller must use a public communication or similarly effective measure. These exceptions must be assessed against the actual breach; encryption helps only if the keys and implementation remained secure.

  • Tell people what happened and what information was affected.
  • Explain the likely effects without speculation or minimising the risk.
  • State what the organisation has done and what the person can do to protect themselves.
  • Keep the high-risk assessment and any Article 34 exception rationale with the breach record.
Citations
UK GDPR Adequacy: When Can You Rely on It?

How do we decide whether adequacy covers a transfer?

First apply the ICO's restricted-transfer test: UK GDPR applies to the processing, your organisation initiates a transfer to an organisation outside the UK, and the recipient is a separate legal entity. If all three conditions are met, check the current ICO adequacy list and the underlying regulation.

Match the destination, territory, sector, recipient, data type, and any eligibility conditions. Record the regulation and date checked. If adequacy covers the transfer, no Article 46 safeguard or TRA is required, but the lawful basis, transparency, security, processor, rights, minimisation, and accountability duties still apply.

  • Map the sender, recipient, locations, roles, data, purpose, access method, and onward transfers.
  • Record why the movement is a restricted transfer before selecting adequacy or another Chapter V route.
  • Check whether the regulation gives full or partial adequacy and whether every scope condition is met.
  • For Canada, confirm the transferred information is subject to PIPEDA; for Japan, confirm the recipient and information fall within the APPI scope described by the decision.
  • For the United States, confirm the recipient participates in and is eligible for the UK Extension to the EU-US Data Privacy Framework.
Citations
UK GDPR Adequacy: When Can You Rely on It?

Which destinations currently have UK adequacy coverage?

The ICO's current list includes full adequacy for the EEA countries and institutions, Andorra, Argentina, Faroe Islands, Gibraltar, Guernsey, Isle of Man, Israel, Jersey, New Zealand, Switzerland, Uruguay, and the Republic of Korea. Canada and Japan have partial coverage under the conditions stated by the ICO. The United States has partial coverage only for eligible transfers under the UK Extension.

Treat this list as time-sensitive. The Secretary of State must monitor relevant developments and amend or revoke approval regulations if the Article 45B data protection test is no longer met. Check the ICO list and regulation when approving a new transfer and on a suitable review trigger.

  • Do not infer adequacy for a territory from a nearby country's status.
  • Do not treat an announcement, negotiation, or policy statement as an in-force approval regulation.
  • Do not assume every Canadian, Japanese, or US recipient is covered.
  • Keep recipient eligibility evidence and monitor changes that could take the transfer outside the regulation.
Citations
UK GDPR Articles 45A to 45C

Binding framework for transfers approved by regulations, the not-materially-lower data protection test, targeted approvals, monitoring, amendment, and revocation.

UK GDPR Adequacy: When Can You Rely on It?

What if adequacy does not cover the transfer?

Use an Article 46 safeguard and complete the data protection test, which the ICO continues to call a transfer risk assessment, or rely on a specific Article 49 exception if its conditions are met. Exceptions are not a substitute for routine safeguards simply because they are easier to document.

If part of a transfer is covered and part is not, separate the data or recipients and document the lawful route for each part. Stop the uncovered transfer if no safeguard or exception can lawfully support it.

Citations
UK GDPR AI and Automated Decisions: Articles 22A-22D

When do Articles 22A to 22D apply?

Identify the decision made about a person, such as refusing credit, rejecting an application, changing access to an essential service, or imposing another outcome with a legal or comparably serious effect. A low-impact recommendation or internal score may fall outside Article 22A if it does not determine or materially shape such an outcome, but the rest of UK GDPR still applies.

Human involvement must affect the decision in practice. A person who automatically accepts a score, lacks authority to change the outcome, or sees too little information to assess it may not provide meaningful involvement. Article 22A requires consideration of the extent to which profiling produced the decision.

  • Record the decision, affected person, effect, data inputs, model output, and final decision-maker.
  • Document the meaningful human involvement that prevents the final outcome from being solely automated.
  • Test whether a human can understand the relevant factors, question the output, and accept, reject, or change the result.
  • Separate automated support from the final decision and test whether the human review works under real workload and time constraints.
  • Reassess when a model, threshold, user journey, data source, or reviewer authority changes.
Citations
UK GDPR AI and Automated Decisions: Articles 22A-22D

Which automated decisions are restricted?

Article 22B restricts a significant solely automated decision based entirely or partly on special-category processing. It is allowed only where the person explicitly consented to all personal-data processing on which the decision is based, or where the decision is necessary for a contract or required or authorised by law and Article 9(2)(g) substantial public interest applies.

A significant solely automated decision also cannot rely entirely or partly on Article 6(1)(ea), the recognised legitimate interests basis. Other significant solely automated decisions are no longer limited to the former contract, law, or explicit-consent routes, but they still need an Article 6 basis and must satisfy fairness, transparency, minimisation, accuracy, security, and other applicable UK GDPR duties.

  • Identify every Article 6 basis and, for special-category data, the Article 9 condition and any DPA 2018 Schedule 1 requirement.
  • Do not use recognised legitimate interests for processing used to make a significant solely automated decision.
  • Complete a DPIA before likely high-risk processing and address discrimination, accuracy, explainability, security, and vulnerable-person risks.
  • Do not treat Article 22C safeguards as permission for processing that lacks a lawful basis or fails another UK GDPR requirement.
Citations
UK GDPR AI and Automated Decisions: Articles 22A-22D

What safeguards and evidence are required?

For every significant solely automated decision based on personal data, Article 22C requires measures that provide the person with information about the decision and enable them to make representations, obtain human intervention from the controller, and contest the decision. Build these routes into the service rather than relying on a general contact address that cannot pause or change the outcome.

Keep a decision inventory, significance and human-involvement analysis, lawful-basis record, DPIA, data and model documentation, accuracy and bias tests, monitoring results, notices, representation and contest workflows, reviewer instructions, response records, and change history.

  • Tell the person that the significant decision was automated and give information they can use to understand and challenge it.
  • Route representations to a reviewer with authority, relevant information, time, and freedom to change the outcome.
  • Record the review, evidence considered, conclusion, communication, and any correction or model-control change.
  • Monitor outcomes and complaints for drift, systematic error, and unequal effects.
Citations
Page 1 of 3
Previous123Next