Search every question across sub-FAQs

Controllers and processors each have record-keeping duties. An organisation with 250 or more employees must document all processing activities. An organisation with fewer than 250 employees still needs to document any activity that is not occasional, is likely to result in a risk to people's rights and freedoms, or involves special-category data or criminal-conviction and offence data.

The three small-organisation conditions are alternatives. Routine payroll, customer management, service delivery, account administration, or monitoring is usually non-occasional even in a small business, so the exemption often removes little from the practical record.

A controller's record must identify the controller and relevant joint controllers, UK representative, and DPO; the purposes; categories of people and personal data; categories of recipients; international transfers and safeguards where applicable; envisaged erasure time limits where possible; and a general description of Article 32 security measures where possible.

A processor's record is narrower but still substantial. It must identify the processor and each controller it serves, relevant representatives and DPOs; the categories of processing carried out for each controller; international transfers and safeguards where applicable; and a general description of security measures where possible.

The record must describe current processing, not the intended design or an old audit snapshot. Update it when a product adds a purpose, data category, recipient, vendor, transfer, retention rule, or material security change. Product, procurement, HR, security, and legal change processes should feed the record owner.

Article 30 does not prescribe a single template. A spreadsheet, governance tool, or connected register can work if the required information is written, understandable, current, and exportable for the ICO. Preserve approval and change history where it helps show when the record changed and why.

Map the data flow and ask who decided to collect or use the personal data, the outcome the processing is meant to achieve, which people and data are in scope, who receives the data, and how long it is kept. Those purpose and essential-means decisions point to controller status. A provider may still be a processor while choosing practical technical details, such as the software or security method used to carry out the controller's instructions.

Two parties are joint controllers only when they jointly determine the purposes and means of the same processing. Parties are not joint controllers merely because they exchange the same data or work toward related commercial goals. Employees acting within their duties are part of the controller rather than separate processors.

The controller is responsible for the lawfulness and fairness of the processing, transparency, rights handling, security, accountability, breach decisions, and choosing processors that give sufficient guarantees. Article 28 requires a binding processor contract or other legal act containing the required terms.

A processor has direct UK GDPR duties. It must follow documented instructions unless UK law requires otherwise, keep data confidential, apply Article 32 security, control sub-processors, assist the controller with rights, security, breach, DPIA, and prior-consultation duties, return or delete data at the end as instructed, and provide compliance information and allow audits. A processor needs the controller's prior specific or general written authorisation before appointing a sub-processor.

Do not classify a cloud or professional-services provider once and reuse the answer for every feature. Hosting to a customer's instructions may be processor activity, while a provider's independent fraud, billing, product-development, or legal-compliance use may make it a controller for that separate processing. The answer depends on the actual facts and the authority each party exercises.

Article 35 states that a DPIA is in particular required for systematic and extensive automated evaluation on which legal or similarly significant decisions are based; large-scale processing of special-category or criminal-conviction and offence data; and systematic monitoring of a publicly accessible area on a large scale.

Also check the ICO's Article 35(4) list and high-risk indicators. Relevant indicators include evaluation or scoring, significant automated decisions, systematic monitoring, sensitive or highly personal data, large scale, combining datasets, vulnerable people, innovative technology, and preventing access to a right, service, or contract. Two indicators often point to a DPIA, but that is not a strict threshold; one may be enough.

At minimum, describe the processing and purposes, including any legitimate interest; assess necessity and proportionality; assess risks to people's rights and freedoms; and describe measures that address those risks, including safeguards, security, and mechanisms demonstrating compliance.

The controller remains responsible for the DPIA. Seek the DPO's advice where a DPO is designated, obtain processor and technical input, and consult affected people or their representatives where appropriate unless doing so would be disproportionate or prejudice commercial or public interests.

If the completed DPIA shows that processing would result in high risk in the absence of measures and the controller cannot reduce that risk, Article 36 requires prior consultation with the ICO before processing. Do not accept or sign off unresolved high residual risk as a business choice and launch anyway.

Review the DPIA when the risk represented by the processing changes. Triggers include new purposes, data, recipients, models, profiling, decisions, vulnerable groups, transfers, security architecture, incidents, complaints, or evidence that a control is ineffective.

The public-authority test uses section 7 of the Data Protection Act 2018. The other two triggers apply to core activities: primary operations needed to achieve the organisation's objectives, not routine ancillary functions such as most employers' internal payroll or HR administration.

Regular and systematic monitoring includes organised, recurring, or methodical tracking and profiling online or offline. To assess whether processing is large scale, consider the number of people, volume and range of data, geographical extent, and duration or permanence. No single numerical threshold decides the issue.

Select the DPO for professional qualities and expert knowledge appropriate to the processing and protections required. A group may appoint one DPO if each establishment can easily access them, and a public body may share one where organisational structure and size allow. The DPO may be an employee or work under a service contract.

Involve the DPO properly and promptly in personal-data matters. Give them resources, access to data and processing, and support to maintain expertise. They must report directly to the highest management level, receive no instructions about how to perform their DPO tasks, and not be dismissed or penalised for performing those tasks.

Article 39 minimum tasks are to inform and advise the controller or processor and staff; monitor compliance, responsibilities, awareness, training, and audits; advise on DPIAs and monitor their performance; cooperate with the ICO; and act as the ICO contact point. The DPO works with due regard to processing risk.

A DPO may perform other work only if it creates no conflict of interests. A role that decides the purposes and means of processing conflicts with independent oversight of those decisions. Assess the real authority of senior management, IT, security, HR, marketing, product, finance, and operational roles rather than relying on job titles.

First confirm that your organisation initiates a restricted transfer and that current UK adequacy regulations do not cover it. Consider whether a specific Article 49 exception applies; for recurring or structured transfers, an Article 46 safeguard is normally the relevant route.

Choose either the IDTA or Addendum. The Addendum attaches UK requirements to the European Commission's 2021 EU SCCs and may suit organisations already using those clauses for EEA transfers. The EU SCCs alone do not support a UK restricted transfer. The IDTA is the standalone UK alternative.

Assess the protection people receive after transfer, taking account of all relevant circumstances and acting reasonably and proportionately. Examine the information and transfer, the selected safeguard, destination laws and practices that may affect it, the likelihood and consequences of access or non-compliance, enforceability and redress, and the effect of contractual, technical, and organisational measures.

If the test identifies a gap, add effective supplementary measures, such as strong encryption with keys inaccessible to the importer or changes that reduce the transferred data, where those measures address the actual risk. If protection remains materially lower for some or all data, do not rely on the safeguard for that portion; use a valid exception if available or stop the transfer.

Keep the data-flow and role map, adequacy and exception checks, executed IDTA or Addendum and incorporated EU SCCs, completed TRA, importer information, destination-law and practices evidence, supplementary measures, approvals, and notices. Record which transfers and onward transfers the pack covers.

A TRA completed before 5 February 2026 does not need to be repeated merely because the legislation now calls it the data protection test. The ICO says a pre-commencement TRA that followed its guidance and concluded protection was sufficient meets the current test. Review it when the facts, law, measures, or risk change.

The ICO currently says to continue using IDTA A1.0 and Addendum B1.0 while it prepares updated instruments during 2026. The parties may choose the instruments' automatic-update mechanism. Also review on changes to the importer, sub-processors, destination, data, purpose, access pattern, security, government-access practices, legal challenge, or ICO guidance.