Technical controls supporting NHS DSPT assurance for UK SMEs

If your organisation handles NHS data, the Data Security and Protection Toolkit, often called the DSPT, is not just a form to complete. In practice, it is a way of showing that the controls around your systems, users, data, and suppliers are working well enough to protect information appropriately.

For UK SMEs, the most useful way to approach DSPT assurance is to focus on the technical controls that reduce risk day to day. That means looking at who can access data, how devices are protected, how information is encrypted, what gets logged, how quickly systems can be restored, and whether third-party services are being managed sensibly.

This article is written for organisations that want a practical starting point. It is not a checklist for every scenario, and it does not guarantee compliance. The aim is to help you build a stronger, more defensible position by improving the controls that matter most.

What NHS DSPT assurance means in practice

Assurance means being able to show that your controls are in place, are being used, and are being maintained. For technical controls, that usually means more than saying a tool has been purchased. You need to be able to explain how it is configured, who is responsible for it, and how you know it is still working.

Why technical controls matter for suppliers handling NHS data

Many SMEs support NHS-related services as suppliers, subcontractors, software providers, or managed service partners. In those cases, technical controls are often the clearest evidence that you are taking information governance seriously. A well-managed access model, reliable patching, secure backups, and sensible monitoring all help reduce the chance of accidental exposure or service disruption.

They also make life easier when you are asked to explain your position to a customer. A business that can describe its controls clearly is usually in a better place than one relying on informal practices or one-off fixes.

How to frame assurance without overclaiming compliance

It is sensible to say that your controls support DSPT assurance. It is not sensible to imply that a single tool, report, or policy means you are fully compliant. Assurance is broader than that. It depends on how controls work together and whether they are consistently applied.

A practical framing is: we have identified the systems and data in scope, we have implemented proportionate technical controls, and we review them regularly. That is a much stronger position than making broad claims that are hard to evidence.

Core technical controls that support DSPT expectations

There is no single technical control that carries the whole burden. The strongest position comes from a sensible baseline across identity, endpoints, data protection, monitoring, and resilience. For SMEs, the goal is not perfection. It is to reduce avoidable risk and make control operation easy to demonstrate.

Identity and access management

Identity and access management is the foundation of most security programmes. In plain terms, it is about making sure the right people have the right access, and that access is removed when it is no longer needed.

For NHS-related data, the most useful practices usually include:

Unique user accounts for each person, rather than shared logins.
Multi-factor authentication for remote access and any system holding sensitive data.
Role-based access, so users only see what they need for their job.
Prompt removal of access when staff leave or change role.
Regular review of privileged accounts, such as administrators.

These are straightforward measures, but they are often where SMEs gain the most value. If your access model is messy, other controls become harder to trust.

Device security, patching, and endpoint protection

Endpoints are the laptops, desktops, and mobile devices people use to access systems. They are often the most exposed part of the environment, especially where staff work remotely or use personal devices in limited ways.

A practical baseline includes:

Supported operating systems only.
Automatic patching for operating systems and common applications.
Endpoint protection or anti-malware tooling with central management.
Full disk encryption on portable devices.
Screen lock and inactivity timeout settings.
Removal or restriction of local administrator rights.

Patching deserves particular attention. A patching process does not need to be complex, but it should be consistent. You should know what assets are in scope, which updates are critical, and how exceptions are approved and tracked.

Protecting data in transit and at rest

Data protection is not only about preventing unauthorised access. It is also about reducing the impact if a device is lost, a connection is intercepted, or a system is misconfigured.

Encryption choices and key management basics

Encryption means making data unreadable without the correct key. In practice, you want encryption for data stored on laptops, servers, backups, and cloud services where appropriate, and for data moving across networks.

For SMEs, the important point is not to chase the most advanced option. It is to make sure encryption is enabled where it should be, and that the keys are protected properly. If encryption keys are stored in the same place as the data, or are shared too widely, the protection is weakened.

Good basics include:

Using built-in encryption features on devices and storage platforms.
Restricting access to encryption keys and secrets.
Separating administrative access from day-to-day user access.
Reviewing whether backups and exports are also encrypted.

It is also worth checking that encryption settings are not just available, but actually turned on for the systems that matter.

Secure remote access and network segmentation

Remote access is common in SME environments, but it should be controlled. Secure remote access usually means authenticated connections, multi-factor authentication, and limited exposure of internal services to the internet.

Network segmentation means separating systems so that compromise in one area does not automatically expose everything else. For example, systems holding NHS-related data can be separated from general office devices, guest networks, or development environments.

You do not need a highly complex network design to benefit from segmentation. Even simple separation, combined with firewall rules and restricted admin paths, can reduce risk and make the environment easier to understand.

Logging, monitoring, and alerting

Logging is the record of what happened on a system. Monitoring is the process of looking for unusual or important activity. Alerting is what happens when something needs attention. Together, they help you detect issues and show that controls are being watched.

What to log and why it helps evidence control operation

For DSPT assurance, logs are useful because they show control activity over time. They can help demonstrate that access is being used appropriately, that changes are being made through approved routes, and that security events are being noticed.

Useful log sources often include:

Authentication events, including failed logins and multi-factor authentication results.
Privileged account activity.
Changes to user accounts, groups, and permissions.
Endpoint security alerts.
Firewall and remote access logs.
Backup and restore events.

It is not necessary to collect everything. The aim is to collect the right information for the risks you face, and to keep it long enough to investigate issues when needed.

Keeping logs useful without creating unnecessary noise

Too much logging can be as unhelpful as too little. If every event creates an alert, staff quickly stop paying attention. A better approach is to decide what matters most, then tune alerts so that they are actionable.

For SMEs, a sensible pattern is to:

Prioritise high-risk events such as privileged access, failed logins, and security tool alerts.
Assign ownership for reviewing alerts.
Document what should happen when an alert is raised.
Periodically check that logs are still being collected and retained.

If you use a managed service for monitoring, make sure you still understand what is being monitored, what thresholds are in place, and how incidents are escalated.

Backup, recovery, and resilience

Backups are often treated as a technical afterthought until something goes wrong. For NHS-related services, they are a core part of assurance because they support availability, continuity, and recovery after accidental deletion, corruption, or ransomware.

Backup design that supports availability and recovery

A good backup design is not just about copying data somewhere else. It should reflect how quickly you need to recover, what data matters most, and whether the backup itself is protected from tampering.

Useful principles include:

Back up critical systems and data regularly.
Keep at least one backup copy separate from the main environment.
Protect backups with access controls and, where suitable, encryption.
Include configuration data, not just user files and databases.
Make sure cloud services are included in the backup plan where needed.

It is also worth checking whether backup retention matches business needs. Keeping data forever is not usually a good answer, but neither is deleting it before it can support recovery.

Testing restores and understanding recovery time

A backup that has never been restored is only a theory. Restore testing is what turns it into evidence. Even a simple test, carried out on a planned basis, can show whether the process works and how long recovery takes.

When testing, ask practical questions: Can the data be restored? Is it complete? Are permissions intact? How long did it take? Did anyone need special access to complete the restore?

That information helps you understand your recovery time in real terms. It also gives you something concrete to show when asked how you know the backup process is effective.

Vulnerability management and secure configuration

Vulnerability management is the process of finding weaknesses, deciding which matter most, and fixing them in a sensible order. Secure configuration means setting systems up in a way that reduces unnecessary exposure from the start.

Asset visibility and patch prioritisation

You cannot protect what you do not know you have. Asset visibility means maintaining a reasonable view of your devices, servers, cloud services, and key applications. For SMEs, this does not need to be a heavyweight inventory system, but it should be accurate enough to support patching and monitoring.

Once you know what is in scope, prioritise by business impact and exposure. Internet-facing systems, remote access tools, and systems holding sensitive data usually come first. Known vulnerabilities in those areas should be addressed quickly, with clear ownership and deadlines.

Where patching is delayed, record the reason and the compensating controls. That is often more defensible than leaving exceptions undocumented.

Baseline hardening and configuration drift

Baseline hardening means removing unnecessary features, services, and permissions so systems start from a safer position. Configuration drift happens when systems slowly move away from that baseline because of ad hoc changes, temporary fixes, or inconsistent administration.

To keep things under control:

Define standard builds for common device and server types.
Disable services and ports you do not need.
Use configuration management where possible.
Review changes to security settings, not just software versions.
Check periodically that live systems still match the approved baseline.

This is especially important where multiple people manage the environment. Without a baseline, it is easy for small changes to accumulate into a larger risk.

Supplier and cloud service considerations

Many SMEs rely on hosted services, managed platforms, and third-party support. That is normal, but it does not remove your responsibility to understand how those services are controlled.

Shared responsibility in hosted services

Shared responsibility means that some controls are managed by the provider and some remain with you. The exact split depends on the service model, but the principle is the same: you should know which party is responsible for what.

For example, a cloud provider may secure the underlying platform, while you remain responsible for user access, data classification, configuration choices, and how the service is used. If you assume the provider is covering everything, gaps can appear quickly.

It helps to document the service, the data it holds, the controls you depend on, and the responsibilities that sit with your organisation.

Checking that third-party controls align with your own

Supplier assurance is not only about questionnaires. It is also about understanding whether the controls in a third-party service are compatible with your own security expectations.

Useful questions include:

Does the supplier support multi-factor authentication?
Can you review access and activity logs?
How are backups handled?
What happens if the service is unavailable?
How are vulnerabilities and security updates managed?

If a supplier cannot support a control you rely on, you may need a compensating control of your own, or you may need to reconsider the service design. That is a business decision as much as a technical one.

Building evidence for a practical submission

Good evidence is usually simple, current, and easy to explain. You do not need a large evidence pack to show that controls exist. You need records that demonstrate the controls are implemented and maintained.

Simple records that show controls are in place and maintained

Useful evidence often includes:

Access review records.
Patch reports or update summaries.
Endpoint protection dashboards.
Backup test results.
Log review notes or monitoring reports.
Configuration baselines or build standards.
Supplier responsibility summaries for hosted services.

These records work best when they are dated, owned, and linked to a regular process. A screenshot taken once is less useful than a repeatable record showing that the control is part of normal operations.

Common gaps SMEs can close early

In practice, SMEs often find the same gaps:

Shared admin accounts.
Inconsistent patching across devices.
Backups that are not tested.
Logs that are collected but never reviewed.
Cloud services with unclear ownership.
Old accounts that were never removed.

These are usually worth fixing early because they are relatively visible, relatively low cost to improve, and often have a direct impact on assurance.

A pragmatic implementation roadmap for SMEs

If you are starting from a mixed or informal environment, do not try to solve everything at once. A phased approach is usually more realistic and more effective.

Start with the highest-risk systems and data flows

Begin with the systems that hold NHS-related data, support remote access, or connect to external services. Map the main data flows, identify who needs access, and check whether the current controls are proportionate to the risk.

That gives you a sensible order of work. It also helps you avoid spending time on low-value improvements while the main exposure remains unchanged.

Sequence improvements by business impact and effort

A practical sequence for many SMEs is:

Fix identity and access issues, especially shared accounts and weak authentication.
Improve endpoint protection and patching.
Confirm encryption for devices, backups, and relevant data stores.
Set up logging and alerting for the most important events.
Test backups and restore processes.
Review supplier and cloud responsibilities.
Document the evidence that shows these controls are operating.

This order is not universal, but it works well when resources are limited. It focuses first on controls that reduce the most common and most damaging risks.

Technical controls supporting NHS DSPT assurance are strongest when they are part of normal business operations, not treated as a one-off project. If you can show that access is controlled, devices are protected, data is encrypted, logs are reviewed, backups are tested, and suppliers are understood, you are already in a much better position.

For many SMEs, the challenge is not finding more tools. It is making the existing controls clearer, more consistent, and easier to evidence. That is usually where a measured, risk-based approach pays off.

If you would like help reviewing your current technical controls and turning them into a more practical assurance story, speak to a consultant.