An ATRS checklist is a board approval test for whether an algorithmic tool must be published under the UK Government's Algorithmic Transparency Recording Standard, what evidence supports that record, who signs it off, and which privacy, ethics, security and governance controls must be ready before launch.
The point is not to make a public record look complete. It is to decide whether the organisation can explain, in public, how an algorithmic tool supports a decision that may affect people. For central government bodies in scope, publication is a mandate. For broader public sector organisations, the same record is often the clearest voluntary evidence of responsible AI use.
Key takeaways
- The Algorithmic Transparency Recording Standard (ATRS) is mandatory for government departments and in-scope arm's-length bodies, and it remains recommended for the wider public sector through the Data Standards Authority route.
- The mandatory trigger is contextual: an algorithmic tool must be recorded when it significantly influences a decision-making process with public effect, or directly interacts with the public.
- A useful board paper separates the publication question from the wider control question: the record, the DPIA where personal data is involved, supplier evidence, redaction rationale and signoff trail are different artefacts.
- The board should decide what is safe to publish before launch, not after a complaint, FOI request or press query.
- ATRS maps naturally to the UK's transparency and accountability principles, the Data and AI Ethics Framework, UK GDPR and, where an organisation uses them, ISO/IEC 42001 and the NIST AI RMF.
Who must publish and who should use it voluntarily
The ATRS Hub says the standard creates a standardised way for public sector organisations to publish information about how and why they use algorithmic tools. It also states that the ATRS is mandatory for all government departments and for arm's-length bodies that deliver public or frontline services, or directly interact with the general public.
The mandatory scope and exemptions policy narrows the tool-level question. An in-scope organisation must publish a record for tools in beta, pilot or production when the tool either has a significant influence on a decision-making process with public effect, or directly interacts with the general public. The same policy says this is about operational decisions about individuals, organisations or groups, not broad analytical models used for policy-making.
That distinction matters for boards. A chatbot that answers public service queries is in the published examples of in-scope tools. A large language model used by an individual civil servant to summarise an internal meeting is given as an example outside mandatory scope. A text recognition tool used for archiving may be outside scope; the same kind of tool used to digitise application forms for a government service may influence individual outcomes and move into scope. The context of use is the decision.
The wider public sector is not free to ignore the standard. The ATRS guidance for public sector bodies says the Data Standards Authority recommends ATRS across the whole public sector, and that records have been welcomed from local government, police forces and other broader public sector organisations. The public repository is the public-facing place where records are searchable by organisation and function.
For a board outside central government, the right decision is therefore not "are we forced?" only. It is whether voluntary publication is the proportionate answer to the public effect of the tool, the sensitivity of the decision and the transparency expectations of funders, regulators, residents, service users or counterparties. Our public-sector go-live guide sets out how an ATRS record sits beside DPIA, NCSC and citation evidence in a real deployment: what a combined authority asks for before AI goes live.
What the board must decide before publication
The board or accountable committee should not approve an algorithmic tool with a vague action that "transparency will be handled later". The ATRS template is divided into Tier 1 summary information for the general public and Tier 2 sheets for specialist audiences, and the template page says all sections should be completed. That means the organisation needs the facts before signoff, not after go-live.
The decision frame is practical:
- Scope: is the organisation in mandatory scope, and does the tool meet one of the tool-level triggers in the scope policy?
- Public explanation: can the team describe the tool in two or three plain sentences, with the decision context and human role clear enough for a non-technical reader?
- Evidence: has the team assembled the datasets, supplier information, model or rules description, performance evidence, equality and accessibility considerations, and operational process map needed to complete the record?
- Publication risk: which fields can be published in full, which need a higher-level description, and which can lawfully be exempted or redacted under the exemptions policy?
- Clearance: has the deploying team, the senior responsible owner and the communications or press team cleared the record, as the guidance expects before GOV.UK publication?
- Update duty: who owns the record when a pilot moves to production, a new dataset is introduced, the operating process changes or the tool is retired?
That is a board decision because it allocates accountability. The delivery team can draft the record. The data protection officer can advise on personal data. The commercial team can obtain supplier evidence. Communications can test plain English and publication risk. But the board should know who is the senior responsible owner, what residual risk is being accepted, and what evidence will be available if the published record is challenged.
The ATRS checklist for board approval
Use this as the evidence pack for an approval paper. It is deliberately written as evidence, not intention, because the ATRS guidance expects a record to go through internal signoff before publication and to be updated when substantive details change.
| Board question | Evidence to see before approval | Usual owner |
|---|---|---|
| Is publication mandatory, voluntary or not proportionate? | Scope note against the organisation and tool criteria in the mandatory policy, including the lifecycle stage | Senior responsible owner |
| What decision or public interaction does the tool support? | Service map showing where the algorithmic tool sits, who uses it, and what a human decides | Service owner |
| Can the public understand the purpose? | Draft Tier 1 summary in clear language, tested with someone outside the project team | Product owner and communications |
| What data, model or rules does it rely on? | Dataset inventory, source and purpose notes, supplier answers, model or rules description at publishable level | Data owner and supplier lead |
| Does personal data or automated decision-making risk arise? | DPIA or documented screening decision, lawful basis note, privacy notice impact and ICO guidance position | Data protection officer |
| What safety, fairness and accessibility checks were run? | Test evidence, bias or equality assessment where relevant, accessibility review, performance metrics and monitoring plan | Risk, policy and delivery leads |
| What must not be published in detail? | Redaction or exemption rationale, aligned to the scope policy and reviewed by legal, cyber and communications | Legal, cyber and communications |
| Who signs off and who updates it? | Written clearance from the deploying team, SRO and communications or press team; named update owner and review trigger | SRO and ATRS single point of contact |
The AI Playbook for the UK Government asks teams to establish performance metrics, test AI systems across scenarios, record red-team behaviour, and use ATRS for public transparency where the organisation is in scope.
The board should insist that supplier transparency is part of procurement, not an afterthought. The mandatory scope policy says public bodies procuring algorithmic solutions should make publication expectations clear in the route to market, and that the primary focus of ATRS is the use case and steps taken to ensure the tool is appropriate in context. That is the commercial control: if a supplier cannot provide enough information to complete the record, the procurement risk belongs in the board paper.
How the record maps to the wider framework stack
ATRS is not a complete AI governance framework. It is the public transparency artefact. A board still needs the operating controls that make the record true, the privacy controls that make the processing lawful, and the assurance loop that keeps the record current. This is the distinction we make in the AI governance framework UK organisations actually need: principles, policy, controls, evidence and assurance must connect.
| Framework or regime | What it adds to the ATRS record | Board evidence |
|---|---|---|
| ATRS | Public information about how and why an algorithmic tool is used, with mandatory central-government scope and voluntary broader-public-sector use | Published or publication-ready record, repository submission trail, update owner |
| UK AI principles | The government response confirms five cross-sector principles for existing regulators: safety, transparency, fairness, accountability and contestability | Principle-to-control map, linked to the AI system register |
| Data and AI Ethics Framework | The framework applies to projects involving data, data-driven technologies, AI, automated decision-making and algorithmic tools, and asks teams to revisit it through the project lifecycle | Completed self-assessment, trade-off record, fairness, privacy, safety and societal-impact notes |
| UK GDPR and ICO | The ICO AI page says AI guidance is under review after the Data (Use and Access) Act 2025, and its ADM consultation closed on 29 May 2026 | DPIA or screening note, lawful basis, privacy information, human-review and challenge route where relevant |
| ISO/IEC 42001 and NIST AI RMF | ISO/IEC 42001 specifies an AI management system; NIST AI RMF is voluntary and intended to improve AI risk management | AI policy, risk assessment, control evidence, management review, monitoring and improvement records |
The mapping matters because a published record can expose a weak control. If a record says the tool supports a caseworker, the operating process must prove the caseworker can overrule it. If a record says bias has been considered, the evidence pack should show what was tested, which population was considered and what monitoring will continue. If a record says a supplier provides the model, the contract should include enough transparency to keep the public record current.
This is also where the UK's "no single AI Act" position becomes operational. The UK framework is principles-based and regulator-led, as we explain in what your board governs instead of a single AI Act. ATRS helps evidence transparency and accountability, but it does not remove UK GDPR duties, equality duties, procurement controls, security review or sector-specific obligations.
Common mistakes that delay publication
Treating central-government scope as the whole question. The mandatory scope is central government today, but the hub and guidance recommend the standard for wider public-sector use. A local authority, police body or public-service supplier may decide to publish voluntarily because the tool affects residents or service users, even where the central-government mandate does not strictly bind it.
Writing for the supplier instead of the public. The guidance says Tier 1 is for a general audience and should explain what the tool is and why it is used rather than overloading the reader with technical detail. A description that only a vendor engineer understands will not satisfy the purpose of public transparency.
Withholding too much. The scope policy recognises national security, gaming, privacy, intellectual property and commercial sensitivity risks, but it also says that publishing a record with limited or desensitised fields is usually preferable to not publishing at all. The board should ask for a reasoned publication position, not a blanket claim that the tool is too sensitive.
Confusing the record with the risk assessment. ATRS explains the tool publicly. It does not replace a DPIA where personal data is processed, an ethics assessment under the Data and AI Ethics Framework, security review, supplier due diligence or operational testing. The board should see the record as one artefact in the evidence pack.
Forgetting that records change. The guidance says substantive changes, including a pilot moving to production, new datasets or a change in the operational process, should trigger an updated template and another clearance cycle. A record that is accurate only on launch day becomes a liability.
Next step: turn the record into operating evidence
Start with one tool that is close to public effect. Run the scope test, complete the public summary, identify the data and supplier evidence, and list the controls that must be true for the record to be honest. If the chain breaks, the issue is not the template. It is the control.
For a quick board baseline, use the Board AI Scorecard before the approval meeting. If the tool is moving toward deployment and you need the evidence pack mapped to ATRS, UK principles, data protection and assurance, commission the AI governance diagnostic. To see how we evidence our own controls, read our security and trust posture, and for implementation examples browse the Governance AI case studies or how we work with boards and delivery teams.
Sources: GOV.UK ATRS Hub; GOV.UK ATRS guidance for public sector bodies; GOV.UK ATRS mandatory scope and exemptions policy; GOV.UK ATRS template; GOV.UK algorithmic transparency records repository; AI Playbook for the UK Government; Data and AI Ethics Framework; GOV.UK response to the AI regulation white paper; ICO artificial intelligence guidance hub; ICO automated decision-making consultation; ISO/IEC 42001; NIST AI Risk Management Framework
