Search every question across sub-FAQs

Teams should run 72-hour breach reporting as an incident workflow: record when the organisation became aware of a personal data breach, assess whether it is notifiable to the ICO, submit the report without undue delay and where feasible within 72 hours, and keep any delayed or phased-reporting rationale with the incident record.

Start with breach facts, affected personal data, likely risk to individuals, containment steps, controller/processor role, ICO notification decision, and whether affected individuals also need to be told.

Useful evidence is incident-specific: awareness timestamp, breach facts, affected categories of personal data and people, containment steps, risk assessment, ICO notification decision, ICO submission receipt, delayed-reporting explanation if relevant, and any Article 34 communication decision.

The common failure pattern is treating every security event the same, missing the awareness timestamp, waiting for a complete investigation before reporting a notifiable breach, or failing to separate ICO notification from communication to affected individuals.

Teams should treat Adequacy under the UK GDPR as a source-linked operating decision: confirm whether the issue affects controller/processor roles, lawful basis, transparency, DPIA, data-subject rights, breach notification, IDTA/Addendum transfers, children data, or ICO enforcement exposure, assign the team that can change the process, and keep evidence showing the action and review trigger.

The safest first step is to identify the controller/processor role, purpose, lawful basis, special-category status, right, breach, transfer, or child-data trigger before assigning the UK GDPR action.

Useful evidence is not just a privacy notice. Keep the source, lawful-basis note, DPIA, rights log, breach assessment, transfer mechanism, processor terms, and approval trail together.

The common failure pattern is copying an EU GDPR answer without checking UK GDPR wording, DPA 2018 limits, ICO guidance, UK transfer tools, PECR overlap, and post-Brexit divergence.

Article 22 is about a decision that is based solely on automated processing and that produces a legal effect or a similarly significant effect for the individual. In plain English, the key question is whether a person is getting a meaningful human decision-maker, or whether the system is deciding on its own.

Teams should treat AI and automated decisions under the UK GDPR as a source-linked Article 22 and AI-governance decision: identify whether the system makes solely automated decisions with legal or similarly significant effects, confirm the lawful basis or Article 22 condition, and define transparency, human review, challenge, DPIA, accuracy, bias, and security controls.

The safest first step is to map the automated decision, the role of any human reviewer, the personal data used, the effect on the individual, and the evidence proving that safeguards work in practice.

Useful evidence is not just a privacy notice. Keep the source, lawful-basis note, DPIA, rights log, breach assessment, transfer mechanism, processor terms, and approval trail together.

The common failure pattern is copying an EU GDPR answer without checking UK GDPR wording, DPA 2018 limits, ICO guidance, UK transfer tools, PECR overlap, and post-Brexit divergence.

Article 30 records are the written records of processing activities that controllers and processors must keep under Article 30. In plain English, they are the internal register that says what personal data you process, why you process it, who receives it, whether you transfer it, how long you keep it, and what security measures you use.

Teams should treat Article 30 Records under the UK GDPR as a source-linked operating decision: confirm whether the issue affects controller/processor roles, lawful basis, transparency, DPIA, data-subject rights, breach notification, IDTA/Addendum transfers, children data, or ICO enforcement exposure, assign the team that can change the process, and keep evidence showing the action and review trigger.

The safest first step is to identify the controller/processor role, purpose, lawful basis, special-category status, right, breach, transfer, or child-data trigger before assigning the UK GDPR action.

Useful evidence is not just a privacy notice. Keep the source, lawful-basis note, DPIA, rights log, breach assessment, transfer mechanism, processor terms, and approval trail together.

The common failure pattern is copying an EU GDPR answer without checking UK GDPR wording, DPA 2018 limits, ICO guidance, UK transfer tools, PECR overlap, and post-Brexit divergence.

Teams should treat Children's Code under the UK GDPR as a source-linked operating decision for online services likely to be accessed by children: confirm whether the issue affects controller/processor roles, lawful basis, transparency, DPIA, data-subject rights, breach notification, IDTA/Addendum transfers, children data, or ICO enforcement exposure, assign the team that can change the process, and keep evidence showing the action and review trigger.

The safest first step is to confirm whether the product or service is likely to be accessed by children, then identify the controller/processor role, purpose, lawful basis, special-category status, right, breach, transfer, or child-data trigger before assigning the UK GDPR action.

Useful evidence is not just a privacy notice. Keep the source, lawful-basis note, DPIA, rights log, breach assessment, transfer mechanism, processor terms, and approval trail together.

The common failure pattern is copying an EU GDPR answer without checking UK GDPR wording, DPA 2018 limits, ICO guidance, UK transfer tools, PECR overlap, and post-Brexit divergence.

Teams should treat Controller And Processor Status under the UK GDPR as a source-linked operating decision: confirm whether the issue affects controller/processor roles, lawful basis, transparency, DPIA, data-subject rights, breach notification, IDTA/Addendum transfers, children data, or ICO enforcement exposure, assign the team that can change the process, and keep evidence showing the action and review trigger.

The safest first step is to identify the controller/processor role, purpose, lawful basis, special-category status, right, breach, transfer, or child-data trigger before assigning the UK GDPR action.

Useful evidence is not just a privacy notice. Keep the source, lawful-basis note, DPIA, rights log, breach assessment, transfer mechanism, processor terms, and approval trail together.

The common failure pattern is copying an EU GDPR answer without checking UK GDPR wording, DPA 2018 limits, ICO guidance, UK transfer tools, PECR overlap, and post-Brexit divergence.

Teams need a DPIA before processing when the type of processing, including the use of new technologies, is likely to result in a high risk to the rights and freedoms of natural persons. Article 35 also says a single DPIA may cover a set of similar processing operations that present similar high risks.

The UK GDPR gives examples of processing that usually requires a DPIA: a systematic and extensive evaluation of personal aspects based on automated processing, including profiling, where decisions produce legal effects or similarly significant effects; processing on a large scale of special category data or criminal conviction data; and systematic monitoring of a publicly accessible area on a large scale.

Useful evidence is not just a privacy notice. Keep the source, lawful-basis note, DPIA, rights log, breach assessment, transfer mechanism, processor terms, and approval trail together.