NHS Website Compliance Checklist 2026: 5 Standards You Need to Score Against

The most useful compliance checklist is not a document someone completes once and files away. It should become a working control used during procurement, discovery, design, development, testing, and release.

Before reviewing individual standards, establish which requirements actually apply to your project. A public information website, patient-facing service, clinical application, and NHS integration may have different evidence requirements.

Start by creating one scoring sheet with the 5 sections in this article. Assign an owner to each requirement and record the evidence source, current status, outstanding action, and target completion date.

For broader context, review the NHS digital compliance standards alongside this checklist. The objective is to understand how requirements connect before asking vendors to demonstrate individual controls.

Use 3 status levels to prevent important requirements from becoming subjective procurement preferences.

Do not allow a vendor to mark every requirement as "supported" without evidence. Ask for the artefact, policy, test result, technical explanation, or responsible owner that demonstrates the claim.

For example, "WCAG compliant" provides little procurement value by itself. A stronger response identifies the conformance target, testing approach, known exceptions, remediation process, and accessibility statement responsibilities.

Place this checklist into the procurement process before vendor responses arrive. That gives suppliers a consistent framework and makes responses easier to compare.

For each requirement, request 4 things:

During healthcare implementations, a structured checklist helps brief NHS Trust projects and identify gaps in DTAC and DSPT evidence before submission.

Your project kickoff should then convert the procurement checklist into delivery tasks. Requirements that depend on architecture, hosting, integrations, content, or testing need owners before development starts.

A vendor response can look complete while still leaving evidence gaps that appear later during assurance.

Use the checklist to identify those gaps early, particularly where multiple teams share responsibility.

The NHS Service Standard is the starting point for assessing how a digital service is designed and delivered. It is not simply a technical checklist for developers.

The NHS Service Standard requires teams undergoing formal assessment to meet the 14 points of the GOV.UK Service Standard plus 3 additional points specific to health and care. According to NHS England's digital service manual, these additional health specific considerations make the standard particularly relevant to NHS service delivery.

The important procurement question is whether your vendor understands these points as service requirements rather than isolated website features.

The 14 points cover areas such as understanding user needs, solving the whole problem, providing a joined-up experience, accessibility, multidisciplinary working, security, performance, and continuous improvement.

For a website project, translate each point into evidence rather than accepting generic statements.

Your checklist should ask:

The exact assessment context matters, so your project team should validate applicability against the current NHS service guidance.

The health specific additions address issues that general government service guidance cannot fully capture.

They require teams to consider the particular context of health and care services, including clinical and operational implications.

Do not treat these 3 points as a final compliance check. Bring them into discovery and service design because decisions made at that stage can affect clinical safety, content, user journeys, and governance later.

One useful implementation approach is to map each health specific point against an actual user journey. For example, ask what happens when a patient moves from public information to an appointment, referral, or another NHS service.

Across recent compliance projects, walking through Service Standard points 2 and 3 together has helped clarify how health specific services should address the complete problem rather than focusing only on the website interface.

Common problems usually involve evidence rather than an obvious missing webpage.

A team may understand user needs but lack documented research. Another may have accessibility testing but no clear remediation ownership. A vendor may describe security controls without explaining how they apply to the actual service architecture.

Before assessment, ask:

If your project needs delivery against these requirements from the beginning, consider NHS compliant website design and development rather than attempting to retrofit governance after development.

DTAC, or Digital Technology Assessment Criteria, provides a structured way to assess digital health technology. Its 5 core criteria are clinical safety, data protection, technical security, interoperability, and usability and accessibility.

That structure matters because a website or digital health tool can appear technically sound while still having gaps in clinical safety, information governance, or accessibility evidence.

Score the following areas separately:

Do not interpret the 5 criteria as 5 documents. Each criterion can require several forms of evidence.

For clinical safety, evidence may involve the appropriate clinical risk management process and identified responsibilities. Data protection may involve privacy documentation, processing arrangements, and data flows.

Technical security should connect to the actual infrastructure. Interoperability should reflect the integrations the service genuinely requires. Usability and accessibility should connect to testing and user experience evidence.

Clinical safety deserves early attention because it can affect the entire delivery approach.

A website providing general health information may have a different risk profile from a digital service that influences clinical decisions, triages users, handles symptoms, or connects patients with care.

During discovery, identify whether the service could influence a clinical decision or patient action. Then determine the appropriate clinical safety responsibilities before design and development progress too far.

A late clinical safety review can force changes to content, workflows, escalation routes, or functionality. Early assessment gives the delivery team a clearer basis for architecture and testing.

Herexa Health provides a useful example of how DTAC and accessibility considerations can be addressed alongside the broader requirements of a healthcare platform rather than treated as isolated final checks.

Build an evidence register rather than collecting files immediately before assessment.

Depending on the project, evidence may include:

A vendor should also explain which evidence it owns and which evidence remains with the NHS organisation.

For a deeper review of the criteria, use our detailed DTAC breakdown as a companion to this checklist.

A procurement response should identify evidence gaps before contract award where possible.

Ask vendors to distinguish between evidence they already hold, evidence they will produce during delivery, and evidence they cannot provide because it belongs to the commissioning organisation.

This simple distinction prevents a common procurement problem where contractual promises appear complete but operational evidence remains undefined.

The Data Security and Protection Toolkit, or DSPT, operates at an organisational level, but website infrastructure can contribute directly to the evidence and risks considered within that wider submission.

The key distinction is important. A website does not become "DSPT compliant" simply because the organisation completes the toolkit.

Instead, your technical environment, suppliers, access controls, information governance processes, and security arrangements need to support the organisation's broader requirements.

For website projects, identify where the web infrastructure intersects with organisational controls.

Review:

The practical objective is to create a clear data and responsibility map.

If a contact form sends information to an external platform, that platform belongs in the review. If website administrators can access sensitive information, their access arrangements belong in the review.

Hosting documentation often describes technical features without demonstrating how those features support the organisation's actual controls.

For example, saying that a hosting provider uses encryption does not establish who manages access, who receives security alerts, how administrative accounts are protected, or what contractual arrangements exist.

Review the entire supplier chain. Hosting, analytics, forms, booking platforms, monitoring tools, support systems, and integrations may all need consideration depending on the information involved.

IPPF demonstrates why this matters for organisations operating across multiple environments. Coordinating compliance documentation across sites requires consistent ownership and evidence rather than separate assumptions for every website.

For a focused infrastructure review, use our guide to DSPT and web infrastructure as a companion resource.

If a vendor manages hosting or technical infrastructure, ask for evidence requirements in the RFP.

Specify what the supplier must provide, when it must be provided, and how changes will be documented after launch.

That turns DSPT from an organisational reporting exercise into a practical project control.

Accessibility should be treated as a service requirement, not a final testing activity.

WCAG 2.2 AA provides the technical accessibility framework, while the Public Sector Bodies Accessibility Regulations 2018, or PSBAR, create additional legal and publication requirements for relevant public sector bodies.

The distinction matters during procurement because conformance testing alone does not complete the organisation's accessibility obligations.

For applicable public sector bodies, the accessibility process includes more than achieving a technical conformance target.

Your project should address:

Procurement documents should require accessibility evidence from the start.

Ask vendors how they test keyboard navigation, focus behaviour, forms, headings, error handling, contrast, responsive layouts, and assistive technology compatibility.

An accessibility statement should not become a generic page added immediately before launch.

It should accurately describe the website's accessibility status, known limitations, contact route, and relevant compliance information according to the applicable requirements.

The statement also needs to stay aligned with the live website. Major releases can introduce new components, content, forms, or integrations that affect accessibility.

Based on our healthcare IT experience, coordinating accessibility statement publication alongside WCAG 2.2 AA testing works better than treating them as separate workstreams. Both should land within the same release milestone.

For a deeper accessibility review, use our complete WCAG 2.2 AA guide for healthcare.

A procurement response should explain how accessibility will be tested, who will perform the testing, when it will occur, and how defects will be prioritised.

Avoid accepting a statement that a supplier "builds accessible websites" without asking for its testing and remediation process.

Accessibility belongs in design review, component development, content production, quality assurance, and release approval.

UK GDPR and PECR affect how your website collects, processes, stores, and communicates information.

The practical challenge is that privacy compliance can become fragmented across forms, analytics, cookies, embedded services, booking systems, marketing tools, and third party integrations.

Your procurement checklist should therefore follow the data rather than simply checking whether a privacy policy exists.

Review every technology that places or reads cookies or similar technologies.

Your checklist should establish:

Do not rely on the presence of a cookie banner as proof that the implementation meets PECR requirements.

During a project, test the actual browser behaviour. Check what loads before consent, what loads after consent, and whether withdrawing consent produces the expected result.

Your privacy documentation should reflect what the website actually does.

Review:

Data Processing Agreements, or DPAs, also need practical review where suppliers process personal data on your behalf.

Do not copy a generic DPA into the procurement pack without checking whether it describes the actual processing relationship. Supplier roles, processing activities, security responsibilities, and subcontracting arrangements need to match the service.

The same principle applies to your privacy notice. If your website changes its forms, booking process, analytics configuration, or integrations, review whether the published information still reflects the service.

Before launch, compare the implemented website against the approved data map and privacy documentation.

That final comparison can catch changes introduced during development that never reached the original privacy review.

A useful release gate asks one simple question: "Does the live implementation still match what we said we would do?"