← All episodes
Episode 1 29 January 2026 · 54:16

Is Your Council Assertion 10 Ready?

Meet the guest

Listen Podcast episode

Download MP3

Or listen in your favourite app:
Watch Get the Video and Slides Full webinar recording, speaker slides & bonus resources

Show notes

In this episode, John talks to Mark Tomkins — Founding Director of Aubergine — about Assertion 10 of the Annual Governance Statement and what councils need to do to ensure compliance for AGAR 2025/26.

Mark walks through the key updates in the 2025 edition of the Smaller Authorities Practitioners' Guide (SAPPP), covering domain name ownership and security, official email use for councillors and officers, website compliance expectations, and the IT and data policies every council should have in place.

Along the way, there's a bit of banter about Star Wars art, tattoos, and the best advice you could give your 18-year-old self (spoiler: buy Bitcoin).

Is Your Council Assertion 10 Ready? — episode artwork

Chapters

Questions answered in this episode

Drawn from our conversation with Mark Tomkins, Founding Director at Aubergine. The answers below are editorial summaries of the discussion — not verbatim transcripts.

What is Assertion 10, and what does compliance require?

Assertion 10 — officially "Digital and Data Compliance" — is a governance requirement introduced in the Practitioners' Guide. It's made up of four things: a council-owned domain name for a generic clerk email, ongoing compliance with website accessibility regulations, an IT policy (this part is new), and continued UK GDPR / Data Protection Act compliance. From AGAR 2025/26 onwards there's a yes/no tick box on the form for it.

Does Assertion 10 apply to councils in Wales as well as England?

The requirement as written is England-only at present, though Wales is likely to have equivalent provisions.

Do councillors have to use the council's official email domain?

The Assertion 10 compliance requirement is specifically for the clerk to use a domain-based email. Councillors are not currently caught by the rule — but they should not use personal email addresses for council business, and they should not forward council email to a personal account. Forwarding moves council data out of a controlled environment into an uncontrolled one. Later editions of the Practitioners' Guide are expected to clarify the position for councillors and staff.

Should the clerk use a role-based email like clerk@, or a personal name?

The council's official address must be role-based — clerk@, town.clerk@, or parish.clerk@. Continuity (and UK GDPR) requires the address not to be tied to a named individual; the clerk isn't always going to be in the seat. A name-based address can exist in addition, but the role-based one is the official one. Beyond the clerk — having chair@ or per-councillor addresses — is entirely up to the council.

Which domains are acceptable for a council website and email? Does it have to be .gov.uk?

As long as the council owns the domain, the suffix doesn't matter — .gov.uk, .org.uk, and .com all meet the requirement. What Assertion 10 actually asks for is that the clerk's email runs on a domain the council owns. Best practice is .gov.uk because it's the top tier, but it's not mandatory.

Can we use .gov.uk for email but keep our website on a different domain?

That's not good practice. If your email is on clerk@smithfieldtowncouncil.gov.uk, your website should be on smithfieldtowncouncil.gov.uk too. Splitting them confuses users, and there's no reason to maintain two domain names when you only need one.

Will moving to .gov.uk email reduce spam?

No — spam volume has nothing to do with the domain suffix. If you're seeing more spam after a switch, that's down to your service provider or the reputation of the IP address the email service runs on. Spam and domain type are independent of each other.

How long should a council keep emails, and what should a new clerk do with thousands of inherited emails?

Data retention length is the council's own choice, with the obvious caveat that the longer data is held, the greater the exposure if something goes wrong. A two-year window for general correspondence — keeping anything within finance, contracts, HR, or regulatory scope separately — is a sensible benchmark. For an inherited mailbox, don't just delete the old material. Take it to council, agree a retention policy, and use that policy as the mechanism to clear historical content.

Can we rely on the accessibility statement provided by our website host?

No. The host didn't write it for you, and the council hasn't ratified it. The accessibility statement is a policy — it has to come from the council, with the council's name above the door. Revisit it every year. A good starting point is the Government Digital Service template, which has been available since 2018 and is kept current; it covers the elements that are legally required. Adapt it to your council, and explicitly call out anything you know isn't accessible — large local-plan documents from principal authorities are often non-compliant and worth flagging in your statement.

Is Lighthouse good enough for checking website accessibility, or do we need WAVE?

Lighthouse is OK but won't pick up everything. WAVE by WebAIM is better. And the alerts matter — they're not just warnings. Things like "click here" non-descriptive link text and non-sequential headings go into alerts rather than absolute failures, but they're still non-compliance and they do need to be addressed.

Should the IT policy cover the use of AI tools like ChatGPT?

Yes. If the council uses AI in any form — even just a clerk opening ChatGPT for help — its use should be defined in the IT policy. State what it's used for (saving time, drafting documents, summarising material), because there's a lot still unknown about how AI handles data. AI is increasingly baked into normal tools without being labelled, so a useful rule of thumb is: if you didn't write it, or watch someone else write it, assume a system wrote it.

Pod-on-the-Parish is brought to you by Scribe and Civic.ly.