4 moderation and records duties UK community teams must document

What to take away

The Ofcom risk assessment record and what it must contain

The Online Safety Act 2023 puts record-keeping duties on user-to-user services, and community platforms with comments, forums or messaging usually fall inside that definition.

The Online Safety Act 2023 sets out the moderation, safety and record-keeping duties that apply, so the assessment is not optional paperwork for most UK community teams.

What goes into the record matters more than the template. Ofcom expects a documented assessment of the risk of harm to users, the measures taken to reduce it, and the reasoning behind each decision. A community manager should be able to point to the date, the author, the version and the evidence behind every judgement.

Start with a service description. Name the features that allow user-to-user interaction, the size and type of the audience, and whether children can access the service. Ofcom's duties differ by service type, so a wrong description at the top makes the rest of the record unreliable.

Then set out the harms. Illegal content, abuse, harassment, self-harm material and fraud all belong in the assessment where they are relevant to the community. Each entry should say what the risk is, who is exposed, and how likely it is.

Next, record the measures. Keyword filters, reporting flows, moderator training, escalation routes and response times all count. The record should link each measure to the risk it addresses, so a reviewer can see the logic rather than a list of tools.

Finally, record the review cycle. An assessment written once and left unopened is weak evidence. Note who reviews it, how often, and what triggers an out-of-cycle update, such as a new feature or a change in audience.

A single entry can be short. For example:

Keep the assessment with the moderation policy it supports. If the policy changes, the assessment should change with it, and the old version should stay on file.

ICO retention records for moderation and member data

Moderation generates personal data: reports, warnings, bans, chat logs and appeals. UK GDPR requires a lawful basis, a retention period and a record of both. The Accountability and governance | ICO guidance explains what organisations must document to show they meet those duties.

The Guide to accountability and governance | ICO sets out the documentation and governance duties that apply to community platforms, including records of processing and data protection impact assessments.

An ICO retention record is the document that ties each data category to a period and a reason. It is separate from the privacy notice, though the two should agree. If the notice says reports are kept for twelve months, the retention record must say the same.

Build it as a table. One row per data category, with the purpose, lawful basis, retention period, storage location and deletion method. That structure makes the record usable when someone asks why a ban log still exists after two years.

The retention and deletion columns for a typical community might look like this:

These periods are typical examples, not legal defaults. Each one needs a written reason tied to its purpose.

Moderation data is the awkward category. A ban record may be needed to enforce a ban, to defend a decision on appeal, or to spot repeat behaviour across accounts. Each of those is a different purpose and may justify a different period.

Member data is broader. Profiles, email addresses, direct messages and event attendance all sit under the same accountability duty but rarely share one retention period. Splitting them in the record is honest and easier to defend.

Deletion has to be evidenced too. A retention record that never shows a deletion is a policy, not a record. Note the date of each scheduled deletion run and who confirmed it.

Under-18s deserve their own line. If children use the community, the retention period for their data should be justified separately, and the record should say how age assurance affects what is stored.

Retention periods should be reviewed when the service changes. A new messaging feature or a new analytics tool changes what is collected, and the record needs to reflect that before the change goes live.

ASA influencer approval records for community content

Community teams increasingly run creator programmes, ambassador schemes and paid partnerships. When money or free product changes hands, the content becomes advertising, and the Advertising codes - ASA | CAP apply. Rule 2.1 requires marketing communications to be obviously identifiable as such. Rule 2.3 requires them to make their commercial intent clear unless the context already shows it.

The approval record is the gap most teams leave open. A screenshot of a post is not approval evidence. What the ASA expects is a trail showing that someone checked the content against the codes before publication.

That trail starts with a brief. The brief should state the campaign, the platform, the required disclosure wording, and any claims that must not be made. A community manager who signs off a creator without a brief has nothing to show later.

Approval should be recorded per item, not per campaign. Each post, story or video needs a date, a reviewer and a note of what was checked. Disclosure placement is the most common failure, so record where the label appears and whether it is visible without tapping.

This is where advertising rules matter for community teams, because a post that looks like a member recommendation can still be an ad. The record should say why the content was treated as advertising, or why it was not.

Keep the creator contract with the approval record. The contract sets the terms, and the approval record shows the terms were followed. Together they answer an ASA query without a scramble through inboxes.

If a post is amended after approval, the record needs a second entry. Approval of an earlier version does not cover the version that ran.

Companies House filing duties for community businesses

Many community operations sit inside a limited company, whether that is a platform, an agency or a membership organisation. Companies House - GOV.UK sets out the registration and filing obligations that apply to those businesses.

The core duties are straightforward: file annual accounts, file a confirmation statement, and keep the register of directors, people with significant control and shareholders up to date. Miss the deadlines and the penalties are automatic.

For community teams, the risk is ownership. A community business often changes hands, adds an investor or issues shares to a creator partner. Each of those events creates a filing duty, and the person running the community is often the last to hear about it.

Confirmation statements are the easiest to forget because nothing seems to have changed. The statement must still be filed within 14 days of the end of the review period, and the company must confirm the information is correct.

Accounts for a private company are due nine months after the year end, and the first accounts have a different rule. A community manager does not need to prepare them, but should know when they are due.

Director changes, registered office moves and company name changes all need filing too. A community that rebrands without filing the name change creates a mismatch between the brand and the register.

VAT and payroll sit with HMRC rather than Companies House, but they belong in the same evidence pack. A community business trading over the VAT threshold has a registration duty, and contractors working on moderation may fall under IR35 rules.

Keep a filing calendar with the company records. Note each deadline, who is responsible, and the confirmation reference once filed. That single page answers most governance questions from a funder or a client.

A single evidence pack that covers all four duties

Four duties, four owners, four folders is how records get lost. The practical answer is one evidence pack, indexed so that any duty can be found in under a minute.

The pack is not a software product. It is a structure: a cover index, a section per duty, and a version log. The index is the part that matters, because it tells a reviewer what exists and where it sits.

Build it as a working document, not an archive. Records should be added as they are created, not assembled the week before an audit. A pack built in a panic is full of gaps.

The pack should name an accountable person for each section. Shared ownership without a name is how a review gets missed.

Every record should carry a version number and a date, and superseded versions should be kept rather than overwritten.

Access matters too. The pack should be readable by someone who was not involved in creating it. If a new community manager cannot follow the index, a regulator will struggle as well.

This is the same discipline that sits behind standards, records and decision evidence in a community service. The records are the product of the process, not a separate job.

Test the pack once a year. Pick a decision, such as a ban or a campaign approval, and trace it from the index to the underlying record. If the trail breaks, fix the structure rather than the individual file.

Worked example: the index entry Ban logs leads to the moderator decision note, then to the appeal outcome.

How community management software can hold the records

Software will not write the assessment for you, but it can hold the records in a way that survives staff changes. The starting point is UK rules, because the platform has to match the duties that actually apply to the service.

Moderation tools usually log actions. A usable record shows the report, the decision, the reason and the reviewer in one place. Check whether the platform captures reasons or only outcomes.

Retention needs to be configurable. If the platform deletes reports after ninety days by default, that setting may conflict with the retention record. Confirm the deletion schedule before it becomes the de facto policy.

Approval workflows are the weakest area in most tools. Few community platforms handle creator content approval, so teams fall back on email. A simple form with a date, reviewer and link to the live post is better than a long email thread.

Filing duties sit outside community software entirely. Companies House and HMRC records belong in the finance system, with a pointer from the evidence pack index so the two connect.

Look for export. A record that cannot be exported is a record you do not control. Being able to produce a dated PDF of moderation decisions is what turns a platform log into evidence.

Access control should follow the duty, not the seniority. The person who reviews influencer approvals does not need the ban log, and the pack should reflect that.

Finally, decide what stays manual. Risk assessments, retention decisions and approval judgements are human work. Software holds the output, dates it and finds it later. That division of labour is what keeps the pack credible.

Common questions