Reviewer data UK GDPR: practical team controls

What review software teams should take away

This guide is for reputation teams handling reviewer data. It turns UK GDPR duties into checks for the records they hold, the workflows they support and the suppliers that process it.

What counts as reviewer personal data under UK GDPR

Reviewer data is personal data whenever it can identify a person, directly or indirectly. That includes a public display name, a profile photo, an email address, a device fingerprint, an IP address, a location tag and the content of the review itself if it describes the reviewer.

A review platform may argue that a pseudonymous handle is not personal data. The test is not the label but whether anyone can single out that person, and in practice most platforms hold account details, payment records or verification data behind the handle.

Under the UK GDPR, the definition of personal data is broad, and the Information Commissioner's Office treats identifiability as a spectrum rather than a switch. A short review with no account may still be personal data if it is linked to a verified purchase.

The Data Protection Act 2018 sits alongside the UK GDPR and sets out how the regime operates in the United Kingdom, including exemptions and the role of the Information Commissioner's Office. It does not narrow the definition of personal data.

Special category data can appear in reviews. A reviewer might mention a health condition, a religious belief, a trade union role or a sexual orientation while describing a service. That raises the bar for a lawful basis and usually requires an additional condition.

Criminal offence data is a separate category. If a review alleges fraud, assault or another offence, the record may include criminal offence data, which has its own restrictions under the Data Protection Act 2018.

Reputation teams often hold more than the public review. They keep case notes, correspondence, escalation logs, screenshots and investigation files. All of that is reviewer personal data if it relates to an identifiable person.

A useful test is to ask whether the record would help someone find, contact or make a decision about the reviewer. If yes, treat it as personal data and apply the same controls as customer records.

Reviewer data also includes metadata. Timestamps, moderation decisions, device signals and fraud scores are all personal data when linked to a reviewer, even if the reviewer never sees them.

Choosing a lawful basis for review collection and monitoring

Every processing purpose needs a lawful basis before you start. Collecting a review, publishing it, moderating it, monitoring it for fraud and keeping it for analytics are separate purposes, and each one needs a basis.

The Information Commissioner's Office publishes A guide to lawful basis that sets out the six options and how to choose between them. For review work, legitimate interests and consent are the two most common.

Legitimate interests suits review collection and fraud monitoring when the processing is expected, low risk and necessary for a genuine business need. It requires a three part test: identify the interest, show the processing is necessary, and balance it against the reviewer's rights.

Consent suits optional uses such as marketing emails, profiling or sharing reviewer data with partners. It must be freely given, specific, informed and unambiguous, and it must be as easy to withdraw as to give.

Contract is rarely the right basis for reviews. A review is not usually necessary to perform a contract with the reviewer, unless the contract itself requires feedback as part of the service.

Legal obligation can apply to retention, complaints handling or responding to a regulator, but it does not justify the original collection of the review.

Public task and vital interests are unlikely to fit commercial review management. If you are a public body, public task may apply to some review functions, but the reasoning should be documented.

You must tell reviewers which basis applies. The privacy notice should link each purpose to a basis in wording a non lawyer can follow, and the basis should match what you actually do.

A common failure is to collect reviews under legitimate interests and then use the same data for marketing under the same basis. That is a purpose change, and it needs its own assessment and notice.

Record your lawful basis assessment. A short document that names the purpose, the basis, the necessity test and the balancing test is enough, and it is the first thing an investigator will ask for.

Retention rules for reviewer data and review records

A retention schedule is a written rule that says how long each type of reviewer data is kept and why. It should cover the published review, the reviewer account, moderation notes, fraud signals, correspondence and analytics extracts.

Retention must be tied to purpose. If you keep reviewer data for fraud prevention, keep it only as long as fraud patterns require. If you keep it for analytics, aggregate or anonymise it and delete the identifiable source.

Published reviews often stay online indefinitely, and that can be lawful when the review is the service itself. The reviewer's account data behind it should still follow a schedule, not an open ended rule.

Moderation notes and investigation files are the highest risk records because they often contain opinions and allegations. Set a short retention period, such as the life of the complaint plus a defined appeal window, and then delete.

Fraud signals and device data should be kept only as long as they are needed to detect and prevent abuse. Keeping raw device data for years is hard to justify when a risk score would do.

Backups are not an excuse for indefinite retention. Set a backup rotation and make sure deleted records age out of backups within a defined period.

When retention ends, delete or anonymise. Anonymisation must be genuine, meaning the reviewer can no longer be singled out, and it should be documented so you can show the data is out of scope.

A retention schedule should name an owner and a review date. Reputation teams change tools and vendors often, and the schedule needs to follow the data, not the platform.

Keep a deletion log. It should record what was deleted, when, by whom and under which schedule rule. This is the evidence that supports your position if a reviewer complains.

Where a review is disputed, a hold may be needed. Document the hold, its reason and its end date, and make sure it does not become a permanent exception.

Subject access requests from reviewers, step by step

A subject access request is a request from a person for a copy of their personal data, and reviewers can make one at any time. You cannot charge a fee in most cases, and you must respond without undue delay and within one month.

The Information Commissioner's Office sets out the full rights framework in its Individual rights - guidance and resources | ICO page, which is the reference point for access, erasure, objection and rectification.

A request can arrive through a review platform, a social media message or a phone call. It does not need to use the words subject access request, and it does not need to be in writing if you can verify the requester.

The one month clock can be extended by two further months for complex requests, but you must tell the requester within the first month and explain why. Complexity is about the request, not your workload.

If you refuse a request, you must explain why, tell the requester about their right to complain to the Information Commissioner's Office, and keep a record of the decision. Refusals are reviewed closely.

A reviewer may ask for the fraud score or moderation note attached to their review. Those records are personal data, and the usual exemptions are narrow. Assume disclosure unless a specific exemption applies.

Erasure, objection and rectification requests in review work

Erasure, often called the right to be forgotten, applies when the data is no longer needed, when consent is withdrawn, when processing is unlawful, or when an objection succeeds. It is not absolute.

A reviewer can ask for their review to be removed, but the platform or brand may have a lawful reason to keep it. Freedom of expression, fraud prevention and legal claims are common grounds for refusal, and each refusal should be reasoned.

Objection is a separate right. If you rely on legitimate interests, a reviewer can object, and you must stop unless you can show compelling legitimate grounds that override their interests.

Rectification covers inaccurate data. If a reviewer says a moderation note is wrong, you must correct it or record that the reviewer disputes it. You do not have to delete a genuinely held opinion.

A disclosure and correction record helps here. It tracks what was disclosed, what was corrected and why, which makes repeat requests easier to answer.

Erasure requests often arrive alongside a request to remove a review. Keep the two decisions separate: the review may stay published while the account data behind it is deleted.

If a review is removed, record the decision and the basis. A deletion without a reason is hard to defend if the reviewer complains or the platform asks for evidence.

For disputed reviews, the route through data protection, from frozen source to deletion evidence shows how to preserve the original record, assess the claim and document the outcome.

When you refuse erasure, tell the reviewer what they can do next, including complaining to the Information Commissioner's Office. Keep the refusal and the reasoning on file.

Controller and processor roles between brands, agencies and platforms

A controller decides why and how reviewer data is processed. A processor acts on the controller's instructions. Most brands are controllers for their own review data, even when a platform hosts the reviews.

A review platform can be a controller, a processor or both, depending on the activity. Hosting and displaying reviews for its own purposes is usually controller activity; running moderation for a brand under instruction is usually processor activity.

Agencies are often processors when they handle reviews on behalf of a brand, but they become controllers if they use the data for their own marketing, benchmarking or product development.

A written contract is required between controllers and processors. It must set out the subject matter, duration, nature and purpose of processing, the type of personal data, the categories of data subjects and the controller's instructions.

International transfers matter. If a platform or agency stores reviewer data outside the UK, you need a transfer mechanism and a transfer risk assessment. Check where backups and support access sit.

Sub-processors must be authorised. If a platform uses a cloud provider or a moderation vendor, the contract should name them or set out how they are approved and how the controller is told about changes.

Joint controllership can arise when two parties decide purposes together. If a brand and a platform jointly set moderation rules and use the data for shared goals, a joint controller arrangement may be needed.

A privacy reviewer role in the reputation team can own the controller and processor map, keep contracts current and check that instructions match what actually happens.

When you buy tools, the contract is part of the compliance picture. Teams selecting review-response software should check data residency, retention controls, deletion capability and audit logs before signing.

Security and breach reporting

Security must be appropriate to the risk. Reviewer data is attractive to attackers because it links identities to opinions, so access control, encryption and logging are baseline controls.

Limit access by role. Moderation notes and fraud signals should not be visible to everyone in marketing, and access should be reviewed when people change roles or leave.

Encrypt reviewer data in transit and at rest. Use multi factor authentication for admin accounts, and log who viewed or exported reviewer records.

A personal data breach is any security incident that leads to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data. A misdirected email can be a breach.

If a breach is likely to result in a risk to people's rights and freedoms, you must report it to the Information Commissioner's Office within 72 hours of becoming aware. The Report a breach | ICO service is the route for that notification.

If the breach is likely to result in a high risk to individuals, you must also tell those individuals without undue delay. That includes reviewers whose identities or contact details were exposed.

Keep an internal breach log even when you do not report. It should record the facts, the effects, the action taken and the reasoning, and it should be reviewed for patterns.

Automated fake-review detection and ICO AI guidance

Automated fake-review detection is processing of personal data. It scores reviewers, flags patterns and can lead to a review being hidden or an account being closed, so it needs a lawful basis and a fairness check.

The Information Commissioner's Office publishes Artificial intelligence | ICO guidance that applies to AI tools used in review moderation, including expectations on lawfulness, fairness, transparency and accountability.

Transparency matters most. Reviewers should be told that automated tools may be used, what signals are considered and what happens if a review is flagged.

Human review is a practical safeguard, but it is not a universal rule for every automated flag. Under the UK GDPR, assess whether a decision is based solely on automated processing and has legal or similarly significant effects; where the applicable safeguards require it, provide a route to human intervention and challenge.

Bias is a real risk. Detection models trained on past moderation decisions can repeat past errors, so test outcomes across regions, languages and reviewer groups, including in Scotland, Wales and the English regions.

Data minimisation applies to model inputs. Use the signals you need, keep them for as long as the model requires, and avoid building long term profiles of reviewers for unrelated purposes.

A data protection impact assessment is likely to be required for large scale profiling or systematic monitoring. It should cover the model, the data, the risks and the mitigations, and it should be reviewed when the tool changes.

Keep a record of automated decisions. If a reviewer asks why their review was removed, you need to be able to explain the logic in ordinary words and show that a human considered it.

Vendors should be able to evidence their compliance. Ask for their lawful basis, their impact assessment, their retention rules and their accuracy testing before you rely on their scores.

A reviewer-data checklist for reputation software teams

Use UK GDPR guidance and resources from the Information Commissioner's Office as the reference set, and work through this practical checklist at least once a year.

Run the checklist as a table too, so each item has an owner and a date.

A worked example shows how the pieces fit. A retailer in the West Midlands collects reviews on its own site and uses a third party tool to score them for fraud.

The retailer is the controller for the reviews and for the fraud scores. The tool vendor is a processor for scoring and a controller for its own model improvement, so the contract needs to separate the two roles.

The lawful basis for collection and fraud scoring is legitimate interests, documented with a balancing test. Marketing reuse of review content is consent based, with a separate opt in.

The retention schedule keeps published reviews while the product is on sale, account data for two years after the last activity, and fraud signals for twelve months. Moderation notes are deleted six months after the case closes.

A reviewer asks for a copy of their data and for their account to be deleted. The team logs the request, searches the platform, the CRM and the fraud tool, redacts a third party name, and responds within the month. The review stays published, the account data is deleted, and both decisions are recorded.

A misdirected email exposes reviewer email addresses. The team assesses the risk, reports to the Information Commissioner's Office within 72 hours, tells the affected reviewers, and logs the incident. The next checklist review adds a check on mailing list segmentation.

Common questions

Do we need consent to publish a review?

Usually no. Publishing a review the reviewer submitted is normally covered by legitimate interests or by the terms of the platform, provided the privacy notice explains it. Consent is better reserved for optional uses such as marketing.

How long can we keep reviewer data?

As long as the purpose requires, guided by a retention schedule. Published reviews may stay online, but account data, moderation notes and fraud signals should have shorter, defined periods and be deleted or anonymised afterwards.

Can a reviewer ask us to delete their review?

Yes, they can ask, and you must consider it. Erasure is not absolute, so you may refuse if you have a lawful reason to keep the review, but you must explain the decision and tell them how to complain to the Information Commissioner's Office.

Who is the controller when a platform hosts our reviews?

The platform is often a controller for its own hosting and display purposes, while your brand is the controller for the review relationship and any data you hold. The contract should set out who decides what for each activity.

Does automated fake-review detection need a human check?

Not for every automated flag. Under the UK GDPR, assess whether a decision is based solely on automated processing and has legal or similarly significant effects. Where the applicable safeguards require it, the reviewer must have a route to human intervention and to challenge the decision.

When must we report a review data breach?

Within 72 hours of becoming aware, if the breach is likely to risk people's rights and freedoms. If the risk is high, you must also tell the affected reviewers without undue delay.