The NHS Cyber Security Charter is a useful public commitment, but the interesting bit starts after the signature. Can the supplier show that the commitments are actually working in the business?

IN SHORT

In short: the NHS Cyber Security Charter is a voluntary supplier commitment, not a certification. Its value is practical: supported and patched systems, MFA, 24/7 monitoring, immutable backups, tested recovery, board-level exercising, incident reporting and secure software should all be capable of being evidenced when an NHS organisation asks.

The Charter sits within the wider NHS supplier assurance and readiness picture. For adjacent operational detail, see DSPT v9 and supplier resilience.

We are on the list too, so this is not advice from the sidelines

Assured Digital Technologies is itself a Charter signatory. That matters to us because the same questions we are encouraging suppliers to ask are questions we should be able to answer too.

The Charter is deliberately not a certification scheme.

Signing the Charter is a statement of intent, not certification, procurement approval or a guarantee of current cyber-security compliance. NHS buyers are still expected to carry out appropriate due diligence and put the assurance they need into contracts (NHS England, 2026a).

So the useful question is not, 'are we on the list?' It is, 'if an NHS organisation we supply asked us to evidence each commitment today, what would we show them?'

That is the standard we think makes the Charter valuable: not the logo, but the discipline behind it.

A signatory is still a supplier that needs to be understood

The signatory list is based on supplier self-declaration. Declarations are reviewed before publication, but inclusion is not independent verification, endorsement or a guarantee of current compliance (NHS England, 2026a).

That is not a weakness in the Charter. It is the point. The Charter sets a clear direction; the supplier still has to operate the controls and the NHS buyer still has to understand the risk.

From commitment to evidence

The Charter commitments are concrete: supported and patched systems, DSPT where applicable, MFA, 24/7 monitoring and logging of critical infrastructure, immutable backups and tested recovery, board-level cyber exercises, timely incident reporting and, for software suppliers, adherence to the Software Security Code of Practice (NHS England, 2026a).

Each of those statements should have something practical behind it. Not a perfect folder. Something current enough to show what really happens.

What that evidence looks like will vary by service and risk. But a policy on its own rarely answers the NHS buyer's real question: is this actually happening?

Charter commitment

What credible evidence might look like

Supported systems and patching

Asset/support-status reporting, vulnerability process, patch records and exception handling

DSPT where required

Current DSPT status, evidence owners and remediation/improvement records

MFA

Conditional access / MFA configuration, privileged-access controls and documented exceptions

24/7 monitoring and logging

Monitoring scope, alerting arrangements, retention, escalation and response process

Immutable backups and tested recovery

Backup design plus actual restore / recovery-test evidence

Board-level exercising

Exercise record, participants, lessons identified and actions tracked

Incident reporting

Escalation route, NHS contacts, regulatory decision process and communication templates

Secure software

Secure-development controls, component management, vulnerability process, maintenance and NHS notification

‘We have a policy’ is not the same as ‘we do this’

A backup policy can say backups are tested quarterly. When was the last successful restore?

An MFA policy can say MFA is mandatory. Are there legacy accounts or service identities outside it?

An incident-response policy can set out notification rules. Has the team ever rehearsed a realistic ransomware scenario?

A vulnerability-management document can require prompt remediation. Can you show what currently sits outside target and why?

A supplier-risk policy can require due diligence. Is there an up-to-date view of the third parties that are actually critical to your NHS service?

AI adoption is a good test of the difference. A business may have an acceptable-use policy while teams have already introduced generative AI, Copilot or AI-enabled SaaS into everyday work. Credible evidence looks more like an approved tool and use-case register, the relevant risk or DPIA decisions, access controls, staff guidance and data-handling rules, some monitoring, a named owner and an escalation route for use cases that do not fit the approved model. The Government's AI Cyber Security Code of Practice points the same way, including tracking AI assets and making sure staff understand the risks (DSIT, 2025).

That gap between written intention and operational reality is where NHS buyer scrutiny usually gets interesting.

The Charter is voluntary. Supplier scrutiny is not.

The Charter remains voluntary, but the wider direction of supplier assurance is becoming more active.

The January 2026 supplier steer positions the Charter as a foundation rather than the end state. The next phase is more direct, proportionate engagement, with key cyber controls discussed and supporting evidence requested where appropriate (NHS England and DHSC, 2026).

This is not positioned as a simple pass/fail audit. The stated aim is to identify risk and agree proportionate remediation.

For suppliers, that is actually a healthier model than pretending assurance is a perfect pass/fail state. The useful position is to know the gaps, understand the risk, assign an owner and be able to explain the remediation.

Use the board exercise to test the business, not the diary

Board-level exercising should not be reduced to a diary entry. Done properly, it is one of the quickest ways to find out whether the business is genuinely ready.

Try this scenario. It is 08:30 on a Monday. A ransomware incident has affected systems used to provide your NHS-facing service. You do not yet know whether data has been accessed. Some NHS organisations are experiencing disruption. Your technical team expects recovery to take at least 24 hours.

Who decides whether the affected NHS organisation is informed? Who speaks to them? Who determines whether personal data may be affected? What can sales tell other NHS opportunities? Who has authority to invoke contingency arrangements? What evidence can you provide that backups are safe? What happens if your incident-response provider is dealing with three other victims at the same time?

If the business is discovering those answers for the first time during the incident, the exercise has already paid for itself.

Software suppliers have another layer to consider

For software suppliers, the Charter directly links the commitment to the Government's Software Security Code of Practice.

That means secure design and development, protected build environments, secure deployment and maintenance, and clear communication with NHS organisations (DSIT, 2026).

A4 links those principles to supplier-assurance mechanisms including the Cyber Security Charter, relevant DSPT status and DTAC (NHS England, 2026b).

For product companies, that means cyber assurance belongs inside the product lifecycle, not as a compliance task bolted on when procurement asks for it.

Make the Charter useful internally

Turn the Charter into a one-page evidence register rather than another policy document.

Give each commitment an owner. Identify the live evidence. Record when it was last tested. Record known exceptions. Agree when it will next be reviewed.

Use the same live information when an NHS buyer questionnaire arrives, when DSPT is reviewed, when Cyber Essentials or ISO work is happening, and when the board runs an incident exercise.

At that point the Charter becomes useful operationally, rather than simply something the organisation once signed.

The useful test is simple

There is real value in suppliers publicly committing to stronger cyber resilience. The signature is just the starting point.

The commercial value shows up when those commitments survive an NHS buyer question, an audit and, ultimately, a real incident.

Take the eight Charter commitments and ask one question against each: 'What would we show an NHS organisation today?'

Where the answer is clear, keep it current. Where it is not, you have just found a useful piece of work before an NHS buyer or incident finds it for you.

Frequently asked questions

Is the NHS Cyber Security Charter mandatory?

No. The Charter is voluntary. Suppliers may still have contractual, regulatory and DSPT obligations independently of whether they sign it.

Does signing the Charter mean an NHS supplier is certified?

No. Inclusion on the signatory list is not endorsement, certification, procurement approval or a guarantee of current cyber-security compliance.

What should a Charter signatory be able to evidence?

Depending on the service, useful evidence includes supported and patched systems, MFA, monitoring and logging, immutable backups and tested recovery, board-level exercising, incident-response processes and secure software practices.

References

NHS England (2026a) Cyber security charter for suppliers to the NHS. Available at: https://www.england.nhs.uk/long-read/cyber-security-charter-for-suppliers-to-the-nhs/ (Accessed: 5 October 2026).

NHS England and Department of Health and Social Care (2026) Implementing proactive cyber risk management in the health and social care supply chain. 21 January. Available at: https://www.england.nhs.uk/long-read/implementing-proactive-cyber-risk-management-in-the-health-and-social-care-supply-chain/ (Accessed: 5 October 2026).

NHS England (2026b) Principle: A4 Supply chain. Available at: https://www.england.nhs.uk/long-read/principle-a4-supply-chain/ (Accessed: 5 October 2026).

Department for Science, Innovation and Technology (2026) Software Security Code of Practice. Updated 15 January 2026. Available at: https://www.gov.uk/government/publications/software-security-code-of-practice (Accessed: 5 October 2026).

Department for Science, Innovation and Technology (2025) AI Cyber Security Code of Practice. 31 January. Available at: https://www.gov.uk/government/publications/ai-cyber-security-code-of-practice (Accessed: 6 October 2026).