Beta evidence checklist
The architecture evidence for beta, as a checklist you can work through or print. Built from the guardrail metadata each time the site is published.
Prototype - testing with users
This section is an early prototype that we are testing with users. It may change a lot, and some of it may be wrong. Check with your solution design authority before relying on it, and tell us what works and what does not through the feedback link above.
Tick what you have, link to where it lives, and bring it to your solution design authority or assessment. Where you cannot meet a Must, record the approved exception .
Print this checklist
Artefacts
Must guardrails
GR-AI-02 Use approved AI services and tenancies - The AI services in the built service run only in approved tenancies, shown in the hosting design and configurationGR-AI-03 Keep a human accountable - Human review and challenge built into the service and tested with users and staffGR-AI-04 Be transparent - Draft Algorithmic Transparency Recording Standard record, and the notice telling users about AI tested with themGR-API-07 Secure every API - These controls built and covered by security testingGR-DATA-06 Protect personal data by design - Approved DPIA, and retention and deletion built and testedGR-DATA-09 Retain and dispose of records properly - Retention schedule identified for each type of record, and disposal built inGR-FE-01 Meet WCAG 2.2 AA - Accessibility audit and assistive technology testing completed, issues fixed, and an accessibility statement publishedGR-FE-02 Use the GOV.UK Design System - The service uses GOV.UK Frontend, with design decisions recording any departuresGR-FE-06 Support Welsh where required - Welsh content and journeys built and tested where the standards applyGR-HOST-01 Use Defra's strategic delivery platform by default - The service runs on the Core Delivery Platform, or under an approved exceptionGR-IAM-01 Use the strategic customer identity services - Integration with Defra Customer Identity built and testedGR-IAM-02 Staff sign in with Microsoft Entra ID - Staff sign in through Microsoft Entra ID with multi-factor authentication, and there are no local staff accountsGR-IAM-03 Authorise on least privilege - Role and group model built, with users, services and pipelines given only the permissions they needGR-IAM-05 No secrets in code - All secrets in a managed store with rotation, using workload identity where possibleGR-IAM-06 Privileged access is controlled and audited - Just-in-time privileged access with phishing-resistant MFA configured, and logged to the security operations centreGR-OPS-05 Be ready for live before you go live - Before public beta, the support model, on-call arrangements, runbooks, incident process and live owner agreed, and the service catalogue entry madeGR-OPEN-01 Code in the open - Repositories public, or the reasons for keeping them private reviewedGR-SEC-01 Follow Secure by Design - Secure by Design activities for beta completed, including controls built and testedGR-SEC-02 Keep a current threat model - Threat model updated as controls are built and testedGR-SEC-04 Encrypt in transit and at rest - TLS 1.2 or higher for all traffic and encryption at rest for every data store, confirmed as builtGR-SEC-05 Scan continuously and fix quickly - Static analysis, dependency, container and infrastructure scanning running in the pipelineGR-SEC-06 Test before go-live and after major change - IT health check before go-live, and a remediation trackerGR-SEC-07 Log for detection and response - Authentication, authorisation failures, administrative actions and data exports sent to the security operations centre, and testedGR-SEC-09 Manage risk explicitly - Residual risks accepted by the right owner through the security exception process, each with an expiry dateGR-DEV-02 All code in Defra source control - All source, infrastructure and pipeline code in the Defra GitHub organisation, with nothing held only by a supplier
Should guardrails
GR-AI-05 Evaluate, monitor and threat model - Evaluation results for accuracy, bias and safety before release, and mitigations for AI threats testedGR-AI-07 Suppliers use AI coding assistants openly and safely - Supplier's agreed list of AI coding assistants and how each runs within Defra-approved terms, the review process for generated code, and disclosure in pull requests or delivery reportsGR-AI-08 Give agents the least privilege they need - Agent permissions configured as designed and tested, including that the agent cannot reach tools it should notGR-AI-09 Get human approval for consequential actions - Approval enforced in the tool layer, with tests showing the agent cannot act without itGR-AI-10 Keep an audit trail of what agents do - Audit records of agent inputs, tool calls, approvals and outcomes produced and sent to security monitoringGR-AI-11 Defend agents against prompt injection - Prompt injection mitigations tested, including attempts to misuse tools and leak dataGR-API-01 API first - API specification written before or alongside the user interfaceGR-API-02 Describe APIs with open specifications - OpenAPI 3 or AsyncAPI documents in the repository, checked in the pipeline against the running APIGR-API-03 Follow government API standards - API design reviewed against the GDS API technical and data standardsGR-API-04 Version and deprecate deliberately - Versioning approach published for each API and eventGR-API-05 No integration through shared databases - Built integrations match the container diagram, with no access to another service's databaseGR-API-06 Use events for change notifications - Event and message definitions described in AsyncAPIGR-API-08 Make APIs discoverable - Entry in the platform API catalogueGR-TECH-03 Plan your exit before you enter - Exit plan agreed, with contracts giving Defra its data and the right to export it in open formatsGR-DATA-01 Every data set has an owner - Information asset register entries with a named owner for each data setGR-DATA-02 Use authoritative sources - The service reads from the authoritative sources as designed, tested with the source ownersGR-DATA-03 Use agreed data standards and identifiers - Data stored and exchanged using the agreed standards, checked in testingGR-DATA-04 Collect once, share safely - Journey design showing users are not asked for information Defra already holds, and data sharing agreements where requiredGR-DATA-05 Describe your data - Published metadata records in UK GEMINI or DCATGR-DATA-07 Open by default - Link to the published open data and its licenceGR-DATA-08 Manage data quality - Data quality measures and regular reportsGR-DATA-10 Handle research data safely - Research data from earlier phases deleted on schedule, and the same controls for beta researchGR-DATA-11 No real personal data in prototypes - Test and research environments use synthetic or anonymised data; any exception agreed through a DPIAGR-DIG-02 Design across organisational boundaries - A map of the whole service, including the parts other teams and organisations deliver, and agreed hand-offs between themGR-DIG-03 Provide assisted digital and offline routes - Assisted digital and offline routes designed and tested with users who need themGR-FIELD-02 Design field tools to work offline - Field journeys tested with no connection, including sync after reconnecting and conflict handlingGR-FIELD-03 Manage and secure every device - Devices enrolled in Defra device management, with encryption, patching, screen lock and remote wipe confirmedGR-FE-03 Progressive enhancement - Core journeys tested with JavaScript turned offGR-FE-05 Design for low bandwidth and rural users - Page weight budget, save-progress design and testing on slow connectionsGR-FE-07 Tell users what is happening when things fail or are slow - The front end shows the designed content when a dependency fails or is slow, tested by switching dependencies offGR-HOST-02 Public cloud first - The service runs in a Defra-managed public cloud tenancyGR-HOST-03 Everything as code - Infrastructure, configuration and pipelines defined as code in the repository, with no manual changes to productionGR-HOST-04 Use managed services before self-managed - Hosting design listing the managed services usedGR-HOST-05 Consistent, disposable environments - Environments created from the same code, and how lower environments avoid real personal dataGR-HOST-06 Host data in the UK - Data location confirmed for every data store and backup as builtGR-HOST-07 Design for the resilience the service needs - Multi-zone design built, and recovery tested before go-liveGR-IAM-04 Separate authentication from authorisation - Authorisation rules written down and covered by automated testsGR-OPS-01 Use the platform's observability tooling - Logs, metrics and traces reaching the platform's observability tooling, and security events reaching the security operations centreGR-OPS-02 Log in a structured, safe way - Structured logs with correlation identifiers, tested to show no secrets or unnecessary personal data are loggedGR-OPS-03 Define and measure service levels - Agreed service level objectives with monitoring and alertsGR-OPS-04 Health checks and graceful degradation - Health endpoints, timeout and retry settings, and a design for when dependencies failGR-OPS-07 Measure performance and cost - Published key performance indicators and cost tags on cloud resourcesGR-OPEN-02 Licence clearly - LICENCE file with the Open Government Licence or MIT licence in every repositoryGR-OPEN-03 Publish safely - Secret scanning and push protection on for every repositoryGR-OPEN-04 Reuse and contribute back - Reuse and upstream contributions noted in ADRs and pull requestsGR-PROD-01 Fund and run products, not projects - A named, long-lived team responsible for the product, with a roadmap beyond the current funding periodGR-PROD-02 Name the product owner and service owner - Named product owner and service owner, recorded in the service catalogueGR-PROD-03 Contribute to platforms rather than working around them - Requests and contributions raised with platform teams, and ADRs where the team worked around a platformGR-SEC-08 Protect the supply chain - Dependencies pinned and verified, and a software bill of materials produced in the pipelineGR-DEV-03 Protect the main branch - Branch protection requiring at least one review and passing checksGR-DEV-04 Continuous integration and delivery - Every change built, tested, scanned and deployed by an automated pipeline, with rollback testedGR-DEV-05 Automated testing at the right levels - Test results from the pipeline at each levelGR-DEV-06 Manage dependencies actively - Dependabot or Renovate configured, software composition analysis in the pipeline, and runtimes on supported versionsGR-DEV-07 Follow shared coding standards - Linting and formatting checks in the pipelineGR-DEV-08 Document as you go - README explaining what the service does and how to run, test and deploy it, with links to its ADRsGR-DEV-09 Record significant decisions as ADRs - ADR log in the repository or linked from its READMEGR-SUS-02 Right-size and switch off - Autoscaling and out-of-hours schedules for non-production environmentsGR-SUS-04 Keep data and pages lean - Data retention settings and page weight measurements
Could guardrails
Sign-off
Detail
Answer
Service
Completed by
Date
Solution design authority
Exceptions or departures (guardrail ids)
Read more on the beta page .