Most businesses worry about ransomware, phishing and sophisticated cyber-attacks. Those threats deserve attention, but a recent NHS incident highlights a quieter risk: ordinary IT work going wrong.
On 18 August 2026, Nottingham University Hospitals NHS Trust lost historical maternity data during routine technical work. A set of pre-written instructions was reused to copy a radiotherapy database. One setting that should have been changed first was missed. The process then ran against the wrong database and overwrote maternity records covering women and babies treated between September 2011 and November 2022.
This was not reported as a hacker attack or ransomware incident. It was a human error during a normal IT task.
The trust has recovered the clinical information needed for patient care, including notes, observations and test results. However, it has not been able to fully restore the historical audit trail showing who viewed records during that 11-year period.
The Information Commissioner’s Office and Nottinghamshire Police were notified. Police are also assessing whether the incident affects Operation Perth, the investigation into maternity deaths and injuries at the trust.
You can read the reporting from the BBC and The Register.
It is a serious incident. It is also a useful warning for every growing business that relies on technology but may not have a large internal IT team.
The uncomfortable lesson: routine work can create major risk
When people think about data loss, they often imagine an obvious disaster: a server fire, a ransomware infection or a malicious insider.
In reality, some of the most damaging incidents begin with a familiar task:
- Copying a database
- Applying a software update
- Changing a firewall rule
- Running a migration script
- Restoring a backup
- Deleting an old account
- Moving files between systems
These tasks are often performed under time pressure. The person carrying them out may be experienced and following a process that has worked many times before. The problem may be a single forgotten setting, an incorrect server name or a command aimed at the wrong environment.
That is why documented controls matter. Good IT security is not only about stopping attackers. It is also about making the safe action the easiest action for your team to take.
The question is not whether your people are careful. The question is whether your systems still protect the business when someone makes a perfectly ordinary mistake.
Why reused scripts and runbooks need extra care
Pre-written scripts and runbooks are valuable. They reduce repetitive work, make processes easier to follow and help an outsourced IT services team deliver consistent support.
But a script is not automatically safe just because it worked last time.
A process created for one database, customer or environment may contain assumptions that are no longer obvious. It might include:
- A fixed database name
- A production server address
- A hidden administrator account
- A default setting for a particular client
- A folder path that differs between test and live systems
- Instructions written for a previous version of the software
The more often a process is reused, the easier it is to treat it as routine. That can lead to skipped checks.
Before a script changes important data, someone should confirm what it will affect. For higher-risk work, a second person should review the instructions, the target system and the expected outcome. Where possible, the process should be tested in a separate environment before it reaches production.
This is a basic principle of effective managed IT services: automation should reduce risk, not hide it.
Separate environments and read-only safeguards
One practical control is to keep development, testing and live systems separate.
A test database should not be able to alter a production database simply because someone has selected the wrong option. Similarly, an account used for reporting should not automatically have permission to delete or overwrite records.
Useful safeguards include:
- Separate development, test and production environments
- Read-only access for reporting and analysis
- Approval before scripts can modify production data
- Clear labels for servers, databases and cloud resources
- Warnings before destructive actions
- Restricted administrator privileges
- A requirement for peer review on high-risk changes
- Automated checks that confirm the intended target
These controls do not make mistakes impossible. They make mistakes easier to spot and harder to turn into a major incident.
For growing companies, this is an important part of building reliable IT infrastructure solutions. As systems expand, informal knowledge and “just ask the person who knows” processes become increasingly fragile.
A backup is not the same as an audit trail
The NHS incident also shows why “we have backups” is not a complete answer.
A backup may help restore the main content of a database: customer records, documents, transactions or clinical notes. But the audit history may be stored separately, updated differently or overwritten at the same time.
An audit trail can show:
- Who accessed a record
- When they accessed it
- What they changed
- Which administrator approved the action
- Whether data was exported or deleted
- How a system was used during an investigation
If the main data is recovered but the access history is missing, the business may still face serious operational, legal or compliance problems.
Under UK GDPR, organisations need appropriate security and accountability measures for personal data. That does not mean every business must keep every log forever. It does mean you should understand which logs are important, how long they need to be retained and whether they can be trusted during an investigation.
This is particularly important for sectors handling sensitive information, including healthcare, finance, professional services and recruitment.
Why restore testing matters more than backup notifications
A successful backup notification only proves that a backup job completed. It does not prove that the business can recover what it needs.
A reliable recovery plan should answer questions such as:
- Can the data be restored to a clean environment?
- How long would recovery take?
- Are permissions and user accounts restored correctly?
- Are audit logs included?
- Can the team recover from an administrator account being compromised?
- What happens if the newest backup is corrupt?
- Who makes the decision to restore?
- Who communicates with staff, customers and regulators?
Backups should also be protected from the same mistake or attack that affects live systems. That is why immutable or otherwise isolated backup copies are important. If an administrator can delete both the live data and every backup from the same account, your recovery plan may not be as strong as it appears.
A tested restore drill is one of the most useful exercises an IT provider can run. It turns a reassuring statement into evidence.
What a responsible outsourced IT partner should provide
Whether you use an internal IT team, a managed security services provider or a combination of both, you should expect clear operational controls.
Your provider should be able to explain how they handle:
Documented change control
Every significant change should have a reason, an owner, a risk assessment, a rollback plan and a record of what happened.
Peer review
High-risk scripts and production changes should be checked by another suitably skilled person before they are run.
Least privilege
People and service accounts should have only the access they need. Temporary administrator access should be controlled and removed when the work is complete.
Tested recovery
Backups should be monitored, protected and restored regularly in a controlled test.
Audit logging
Important administrative actions and access to sensitive systems should be logged, protected from unauthorised alteration and reviewed when appropriate.
Clear escalation
If something goes wrong, everyone should know who to contact, what to preserve and when to involve senior management, legal advisers, insurers or regulators.
These are not luxury controls for large enterprises. They are practical foundations for IT support for growing businesses, where a small number of people may be responsible for a rapidly expanding technology estate.
Key Insights
The Nottingham incident offers several lessons:
- Not every major data incident is a cyber-attack. Routine technical work can cause serious damage when controls are weak.
- Reusable scripts need reusable checks. A trusted process still needs its target, permissions and settings confirmed every time.
- Backups and audit logs are different assets. Recovering the data does not necessarily recover the history of access and change.
- Restore testing is essential. A backup that has never been restored is an assumption, not a recovery plan.
- Security includes operational discipline. Change control, peer review and least privilege protect against mistakes as well as attackers.
A practical checklist for this month
Ask your IT provider these questions:
- Which of our systems contain sensitive or business-critical data?
- What would stop a script being run against the wrong database?
- Does anyone review high-risk changes before they happen?
- Are our production systems separated from test environments?
- Which accounts can delete or overwrite data?
- Are backups immutable or isolated from normal administrator accounts?
- When was our last successful restore test?
- Do our backups include audit logs and configuration data?
- How long are important access logs retained?
- What is the escalation process if data is changed or deleted accidentally?
If you manage IT internally, start with three actions:
- Make a list of your critical systems and the data they hold.
- Review administrator and service-account permissions.
- Schedule a restore test and record what worked, what failed and what needs improving.
You do not need to solve everything in one week. You do need to know where the biggest risks are and who owns the next step.
At Picnic IT, we help growing businesses combine dependable support with practical security controls, from managed cyber security to managed hosting. Whether you are looking for outsourced IT services, business IT support in London or a longer-term technology partner, the goal should be the same: systems that are secure, recoverable and properly managed.
The most important IT control may not be the newest security product. It may be the simple pause before someone presses “run”.
Talk to the Picnic IT team if you would like to review your backup, access and change-control arrangements.