Live evidence checklist
The architecture evidence for live, 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 - List of AI services in use, reviewed when services or agreements changeGR-AI-03 Keep a human accountable - Records of human review, challenges raised and their outcomes, reviewed regularlyGR-AI-04 Be transparent - Link to the published Algorithmic Transparency Recording Standard record, kept currentGR-API-07 Secure every API - API access reviewed, and controls re-tested after significant changeGR-DATA-06 Protect personal data by design - DPIA reviewed when processing changes, and deletion running as designedGR-DATA-09 Retain and dispose of records properly - Retention applied and records of permanent value identified for The National ArchivesGR-FE-01 Meet WCAG 2.2 AA - Accessibility statement kept current, and accessibility re-tested after significant changeGR-FE-02 Use the GOV.UK Design System - GOV.UK Frontend kept up to dateGR-FE-06 Support Welsh where required - Welsh content kept in step with English contentGR-HOST-01 Use Defra's strategic delivery platform by default - The service still runs on the platform, and any exception is reviewed before it expiresGR-IAM-01 Use the strategic customer identity services - No other sign-in introducedGR-IAM-02 Staff sign in with Microsoft Entra ID - Staff access reviewed regularly through Entra ID groupsGR-IAM-03 Authorise on least privilege - Record of regular access reviewsGR-IAM-05 No secrets in code - Secrets rotated, and secret scanning alerts dealt withGR-IAM-06 Privileged access is controlled and audited - Privileged access reviewed regularlyGR-OPS-05 Be ready for live before you go live - Runbooks and support arrangements tested and kept currentGR-OPEN-01 Code in the open - Repositories still public, or private for a recorded reasonGR-SEC-01 Follow Secure by Design - Secure by Design activities for live continuing, including monitoring and reviewGR-SEC-02 Keep a current threat model - Threat model reviewed at least once a year, with the date of the last reviewGR-SEC-04 Encrypt in transit and at rest - Encryption settings checked when new stores or connections are addedGR-SEC-05 Scan continuously and fix quickly - Time taken to fix critical and high vulnerabilities, within 14 and 30 days, or a recorded risk decisionGR-SEC-06 Test before go-live and after major change - IT health check after significant change, with remediation trackedGR-SEC-07 Log for detection and response - Security events reviewed and alerts acted onGR-SEC-09 Manage risk explicitly - Accepted risks reviewed before they expireGR-DEV-02 All code in Defra source control - All changes made in the Defra GitHub organisation
Should guardrails
GR-AI-05 Evaluate, monitor and threat model - Monitoring of model performance and drift in live, with evaluation repeated when the model or data changesGR-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 reviewed regularly, as for a privileged userGR-AI-09 Get human approval for consequential actions - Approval records reviewed, and the classification updated when the agent gains new toolsGR-AI-10 Keep an audit trail of what agents do - Audit records retained and reviewed, and used to investigate any problemGR-AI-11 Defend agents against prompt injection - Prompt injection defences re-tested when inputs, tools or models changeGR-API-02 Describe APIs with open specifications - Specifications kept in step with every released changeGR-API-03 Follow government API standards - API design reviewed against the GDS API technical and data standardsGR-API-04 Version and deprecate deliberately - Deprecation notices sent to consumers and retirement dates published for old versionsGR-API-05 No integration through shared databases - Integrations reviewed when the service or its dependencies changeGR-API-08 Make APIs discoverable - Entry in the platform API catalogueGR-TECH-03 Plan your exit before you enter - Exit plan reviewed at contract renewal, with switching cost estimatedGR-DATA-01 Every data set has an owner - Register entries and owners kept currentGR-DATA-02 Use authoritative sources - Copies and refresh arrangements reviewed when sources changeGR-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 handled the same way for ongoing research, and deletion checkedGR-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 - Device compliance monitored, and lost devices wipedGR-FE-07 Tell users what is happening when things fail or are slow - Failure and delay content kept accurate as dependencies and processing times changeGR-HOST-02 Public cloud first - No on-premises hosting introducedGR-HOST-03 Everything as code - Drift detection running, and no manual changes to production in the change historyGR-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 checked when new stores or services are addedGR-HOST-07 Design for the resilience the service needs - Recovery tested at least once a year, with the date of the last testGR-OPS-01 Use the platform's observability tooling - Dashboards and alerts in use by the team that runs the serviceGR-OPS-02 Log in a structured, safe way - Logging reviewed when new data or features are addedGR-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-06 Learn from incidents - Post-incident reviews and the actions takenGR-OPS-07 Measure performance and cost - Published key performance indicators and cost tags on cloud resourcesGR-OPEN-02 Licence clearly - LICENCE file in every new repositoryGR-OPEN-03 Publish safely - Secret scanning alerts dealt with promptlyGR-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-PROD-04 Plan for the end of a product's life - Product lifecycle stage recorded, with a retirement plan for products being replacedGR-SEC-08 Protect the supply chain - Software bill of materials kept current, and supplier assessments reviewed at renewalGR-DEV-03 Protect the main branch - Branch protection still in place on every repositoryGR-DEV-04 Continuous integration and delivery - Deployment history showing small, frequent, reversible releasesGR-DEV-05 Automated testing at the right levels - Test results from the pipeline at each levelGR-DEV-06 Manage dependencies actively - Dependency updates merged promptly and runtimes upgraded before they go out of supportGR-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 live page .