CMA online reviews rules: what UK review tools must log

What to take away

What the DMCC Act 2024 changed for review logging in the UK

The Digital Markets, Competition and Consumers Act 2024 is the statutory footing for banned fake reviews and CMA direct enforcement powers. Before it, the CMA generally had to go to court to enforce consumer law breaches. Now it can decide a breach itself and impose penalties.

That change moves the evidential burden onto the tool. If the CMA can fine a business without a court hearing, the file that supports or contradicts a review claim becomes the first thing a compliance lead is asked to produce.

The Act bans fake reviews and makes it unfair to publish them, commission them or arrange for someone else to publish them. It also covers hiding negative reviews and presenting reviews in a misleading way. The wording is broad enough to catch a review platform that lets a seller suppress one-star ratings without telling the reader.

For a UK review tool, the practical effect is that logging is no longer a nice-to-have. A tool that stores only the star rating and the comment text cannot show whether the review was genuine, whether it was incentivised, or who approved it.

There is a second change that matters for buyers. The CMA can now act on its own findings, so investigations move faster. A tool that takes weeks to produce a review history is a liability during a CMA enquiry, not just an inconvenience.

The CMA's online reviews work and what it asks tools to retain

The Online reviews - GOV.UK guidance shows the pattern of what the CMA asks for: a platform or seller should be able to show how a review reached publication, and what checks ran before it did.

The Consumer protection guidance for businesses - GOV.UK sets out the standard: a business should be able to demonstrate that its reviews are genuine and that it has taken reasonable steps to prevent fake ones. That is an evidence standard, not a design standard.

In practice, the CMA asks for the chain of custody. Where did the review come from? Who submitted it? What checks ran? Who approved it? What happened when a complaint arrived? A tool that cannot answer those questions in sequence is answering a different question.

It also asks about patterns. A cluster of five-star reviews posted within minutes from the same network is a signal, and the CMA will want the tool to show whether that pattern was detected and what was done about it.

Retention matters here. If a tool deletes review metadata after 90 days, the business may have no record of the pattern by the time the CMA asks. The retention schedule has to be set before the request arrives, not after.

Evidence fields a UK review tool should capture per review event

A review event is any change to the state of a review: submission, edit, moderation decision, publication, suppression, complaint or removal. Each event should carry the same core fields.

A status matrix for UK review work forces the tool to name the state a review is in, rather than treating publication as a single moment. The six states are submitted, in moderation, published, under complaint, suppressed and removed, and the matrix below shows what has to be recorded before a review can enter each of them.

A table like this is the minimum. The important discipline is that every field is populated at the moment of the event, not reconstructed later from memory or email.

Three fields are commonly missed. Timezone is one, because a cluster of reviews looks different depending on which clock you use. Actor identity is another, because shared admin accounts destroy attribution. The third is the reason code, because "removed" without a reason is not evidence of anything.

A tool should also record the negative case. If a review was left up despite a complaint, the file should show that decision and who made it. The CMA is as interested in what was not removed as in what was.

Audit trail design: timestamps, actor identity and version history

The audit trail is the part of the tool that survives scrutiny. It should be append-only, so an entry cannot be edited or deleted without leaving a trace.

Timestamps need three properties: they must be generated by the system, stored in UTC with the local offset, and never overwritten. A timestamp a user can type is not a timestamp.

Actor identity means a named human or a named system process. Shared logins, generic admin accounts and "support team" labels all fail the test, because they do not identify who acted.

Version history should show the review as it was at each point. If a review text was edited after publication, the earlier version should remain visible alongside the current one, with the edit time and the editor.

A disclosure and correction record belongs in the same trail, so that any correction to a review or a claim is versioned rather than silently replaced.

The trail should also record the tool's own automated actions. If a filter auto-rejected a review, the rule, the version of the rule and the outcome all belong in the log. Automated decisions are still decisions.

Finally, the trail has to be exportable. A CSV or PDF export that a compliance officer can read without the vendor's help is worth more than a dashboard screenshot.

Endorsement and incentivisation records under CMA consumer guidance

Endorsement disclosure UK rules apply whenever a review, rating or social post is connected to a payment, gift, discount or free product. The reader has to be able to tell.

The CMA's guidance treats a hidden incentive as a misleading practice. That means the record is not just the payment; it is the disclosure shown to the reader and the point at which it was shown.

A tool should log four things for any incentivised review: what was offered, who received it, the disclosure wording used, and the date the disclosure was displayed. If the disclosure was added later, that date matters too.

This is where a review tool often overlaps with a marketing team's influencer work. The same review may sit in a CRM, a gifting platform and a review widget. The log should name the other systems and the identifier used in each.

A useful test: could a reader have known about the incentive before reading the review? If the answer is no, the record is incomplete, whatever the contract says.

Staff reviews and owner reviews need the same treatment. A review written by an employee without disclosure is an endorsement problem, and the tool should be able to flag the relationship.

Where the CPUT Regulations 2008 still bite on legacy review claims

The Consumer Protection from Unfair Trading Regulations 2008 remain in force and still cover misleading commercial practices including fake reviews. They have not been repealed by the newer Act.

That matters for legacy content. Reviews published in 2019, a supplier contract signed in 2021, or a marketing claim made before the new regime can still be assessed under the 2008 Regulations.

A review tool should therefore hold enough context to assess an old claim on its own terms. The record needs the date, the wording as published, and the basis on which it was made.

The 2008 Regulations also cover omissions, not just false statements. Regulation 5 covers misleading actions and regulation 6 covers misleading omissions, so a tool that hides the fact that reviews were filtered, or that a rating excludes a whole channel, can create a misleading impression without a single false word.

The practical step is to tag legacy reviews by the regime that applied when they were published. That tag lets a compliance lead answer a question about a 2020 review without guessing which rules applied.

Where a legacy review is still live, the safest course is to bring it up to current standards. Reassess the disclosure, the verification and the moderation record, and log the reassessment.

A retention schedule that survives a CMA information request

A retention schedule for a CMA information request should be built backwards from the request. The DMCC Act 2024 gives the CMA the power to require information from a business as part of its consumer protection enforcement, so assume the request asks for every review event in a category over a defined period, and design so that answer is possible.

A reputation workflow that moves a case through those six states makes retention easier, because each state has an owner and a date, and the schedule can be tied to state transitions.

The schedule below is a working model. Adjust the periods to your sector, but keep the logic: the more a record supports a public claim, the longer it stays.

Six years is a common choice because it aligns with the limitation period for simple contract claims in England and Wales. It is a planning assumption, not a legal rule for every record.

Data protection law still applies. UK GDPR and the Data Protection Act 2018 mean you cannot keep personal data indefinitely just because a regulator might ask. Keep the review record, and keep personal identifiers only as long as you have a lawful basis.

A practical compromise is to keep the review event record with a pseudonymised reviewer identifier, and hold the link to the identifiable person in a separate store with tighter access.

Before you rely on the schedule, run this check:

If any box is unticked, fix it before a request arrives. A CMA information request gives you a deadline, not a project plan.

Common questions